GET /api/v1/repos/:owner/:name/forks carries an ETag and answers a repeat with 304 until a fork is made, pushed or hidden, or the parent moves #9172

GET /api/v1/repos/:owner/:name/forks now sends a weak etag and answers a repeat that holds it with a 304. The new test/forks-etag.test.ts passes (5 tests). Four of the five fail with the change stashed; the 404/bad-page test passes either way because those responses were already untagged. tsc and scripts/gate.ts are clean. The tsc and gate passes ran on the working tree before I changed the two vary assertions in the test, and I did not re-run them after that edit.

• Headers: the 200 and the 304 both carry etag, cache-control: private, no-cache and vary: authorization, cookie. The 304 has no body and keeps the securityFloor headers.
• Etag: it comes from weakEtag over the exact body bytes, so a fork made, deleted or pushed, a parent moving, or a different limit or cursor changes the tag.
• Private forks: the body is the viewer's own visible forks, so someone who can't see a private fork gets a different tag and a fresh 200.
• Errors: a 404 or a bad page parameter returns before the tag is built and carries none.
• Scope: the change is in src/http/api/upstream.ts only; src/http/api.ts and the response body are untouched.
• vary: the server also appends Accept-Encoding, so the test checks that vary contains authorization, cookie rather than equals it.

The etag is computed after drift is read, so a 304 saves bandwidth but not the drift reads; I did not build a cheaper key. A 304 is also not skipped by the "drift" timing phase, unlike the map route.

To try it, request the forks URL twice, sending the first response's etag as If-None-Match the second time.

Closes #9168

GET /api/v1/repos/:owner/:name/forks now sends a weak etag and answers a repeat that holds it with a 304. The new test/forks-etag.test.ts passes (5 tests). Four of the five fail with the change stashed; the 404/bad-page test passes either way because those responses were already untagged. tsc and scripts/gate.ts are clean. The tsc and gate passes ran on the working tree before I changed the two vary assertions in the test, and I did not re-run them after that edit.

• Headers: the 200 and the 304 both carry etag, cache-control: private, no-cache and vary: authorization, cookie. The 304 has no body and keeps the securityFloor headers.
• Etag: it comes from weakEtag over the exact body bytes, so a fork made, deleted or pushed, a parent moving, or a different limit or cursor changes the tag.
• Private forks: the body is the viewer's own visible forks, so someone who can't see a private fork gets a different tag and a fresh 200.
• Errors: a 404 or a bad page parameter returns before the tag is built and carries none.
• Scope: the change is in src/http/api/upstream.ts only; src/http/api.ts and the response body are untouched.
• vary: the server also appends Accept-Encoding, so the test checks that vary contains authorization, cookie rather than equals it.

The etag is computed after drift is read, so a 304 saves bandwidth but not the drift reads; I did not build a cheaper key. A 304 is also not skipped by the "drift" timing phase, unlike the map route.

To try it, request the forks URL twice, sending the first response's etag as If-None-Match the second time.

I made no change and pushed nothing, because I found nothing in the code to fix.

The deploy log you pasted shows pull #9172 starting, answering and finishing: ready, serving and done all appear, and the log has no error. The "no tests declared, none run" line is only the preview's status note. forge.json has no app.test entry, and the forge runs its tests through the check block on each push instead.

Before the first push I ran tsc --noEmit and bun scripts/gate.ts; both were clean, as was bun test test/forks-etag.test.ts. Those were run before I loosened the vary assertions in the test, and I did not re-run them after that edit. I didn't re-run them this turn.

If the preview is still marked failed, the cause is probably the missing test entry in forge.json, which is outside this issue's files. A failing check result would come back to me with its log; I haven't received one.

The gate failed because no commit message had a Try: line. I added an empty follow-up commit (1cc40cea) with that line and pushed it. The code is unchanged.

Run bun scripts/gate.ts locally and it printed nothing, so the "say how to try it" rule no longer trips. I didn't re-run tsc or the tests, since no code changed since they last passed. The forge's check on this push will confirm the rest.

Try: GET /api/v1/repos/<owner>/<name>/forks on the preview. Then repeat it with the returned etag in If-None-Match and expect a 304 with no body.

Both of @sentinel's points are fixed in test/forks-etag.test.ts and pushed (abaf1c2b). The route code is unchanged. tsc, bun scripts/gate.ts and the five tests in that file pass.

• Private-fork test (box 4): once bob's fork is private, bob with a bearer token and an anonymous viewer request the same URL. The two tags differ, bob's response contains "bob" and the anonymous one doesn't. Bob's tag sent as If-None-Match by an anonymous request gets a 200 with no "bob" in the body. Bob's own repeat with his tag is still a 304.
• Import: deleteRepo is now imported at the top with the other actions/repos.ts imports.

I didn't re-run the earlier check that four of the five tests fail without the route change.

Try: GET /api/v1/repos/<owner>/<name>/forks on the preview as the owner of a private fork and anonymously. The tags differ, and the owner's tag gives the anonymous request a 200.