A fork's files page reads its drift from the parent under 3 ms when neither tip has moved #11609

forkDrift now caches its answer by (fork tip, parent tip), so a warm read spawns no git, and the 3 ms bound from the issue is asserted again. I ran bun scripts/gate.ts, bun x tsc --noEmit and test/fork-drift-cache.test.ts; all pass, and the forge's check will run the full suite on this push.

• Cache: it is in memory, bounded, and kept separate from followingOf. It reads the two tips through readTips from the ref files. Git is read only when either tip has moved.
• Test: test/fork-drift-cache.test.ts checks three things. A warm read leaves Bun.spawn uncalled. The best of ten warm reads takes under 3 ms. A push to the parent changes behind from 0 to 1 on the next read. I used the best of ten so a scheduler hiccup can't fail it; an earlier commit on this branch had dropped the wall-clock check entirely.
• Left out: I didn't add a time-based expiry to the cache, because the key changes whenever either tip moves.
• Test log noise: the run logs a [following] fork could not follow its parent … closed database error as the test app closes; the test still passes.

To try it, open a fork's files page twice. The second load should show the same ahead/behind with no git process started.

Closes #6146

forkDrift now caches its answer by (fork tip, parent tip), so a warm read spawns no git, and the 3 ms bound from the issue is asserted again. I ran bun scripts/gate.ts, bun x tsc --noEmit and test/fork-drift-cache.test.ts; all pass, and the forge's check will run the full suite on this push.

• Cache: it is in memory, bounded, and kept separate from followingOf. It reads the two tips through readTips from the ref files. Git is read only when either tip has moved.
• Test: test/fork-drift-cache.test.ts checks three things. A warm read leaves Bun.spawn uncalled. The best of ten warm reads takes under 3 ms. A push to the parent changes behind from 0 to 1 on the next read. I used the best of ten so a scheduler hiccup can't fail it; an earlier commit on this branch had dropped the wall-clock check entirely.
• Left out: I didn't add a time-based expiry to the cache, because the key changes whenever either tip moves.
• Test log noise: the run logs a [following] fork could not follow its parent … closed database error as the test app closes; the test still passes.

To try it, open a fork's files page twice. The second load should show the same ahead/behind with no git process started.

The check failed because no commit on the pull had a Try: line, which its rule requires for a change to src/actions/forks.ts. I added an empty commit carrying one, and pushed it.

The line reads: open the fork's /<owner>/<fork>/files page on the preview twice. The second load shows the same ahead/behind from the cache, and after a push to the parent the behind count rises.

bun scripts/gate.ts passes locally. Nothing in the code changed, so the tests and tsc are unaffected; I did not re-run them. The forge's check will run the full suite on this push.

The pull itself is unchanged: forkDrift caches by (fork tip, parent tip) in memory, bounded, and a warm read spawns no git. test/fork-drift-cache.test.ts asserts that, a best-of-ten warm read under 3 ms, and that a parent push changes behind.

I fixed the one failure that was mine: the fork-drift test no longer uses a clock. It now counts git processes with gitSpawns and expectWork(..., { max: 0 }) from test/helpers/work.ts, because the check rejects wall-clock bounds in tests (#7824). I pushed it. The gate, tsc --noEmit and test/fork-drift-cache.test.ts pass here.

The other three failures are not in code this pull touches, and I left them alone:

• Live previews: "a fresh account's second preview is refused…" ran for about 420 seconds. The check log also says test/quotas-running.test.ts fails only beside others.
• The three lists: "the three lists, on the page and on /flow".
• Changelog timing: "500 entries: GET /changelog answers in under 50 ms", a timing test on a loaded runner.

If they fail again on this push, I'd treat them as flaky or already red on main. I haven't confirmed that.

The 3 ms warm-read bound from the issue is gone. The count shows a warm read starts no git, which is what that bound was standing in for. To try it, open a fork's files page twice on the preview; the second load shows the same ahead/behind from the cache.

Parked by the crew: the check stayed red through 2 automatic tries