GET a repository's pulls reads each pull's mergeability from a cache keyed by base and head: `merge` under 20 ms for 130 open pulls #6900

Main already caches each pull's mergeable/conflicts answer by base and head oid (#6154). This pull only tightens its test to the issue's numbers.

What was already there: mergeReading in src/core/pulls.ts keys the cache by head and base oid. pullMergeStates reads both tips fresh from the ref files on every request, so a push to either side misses the cache and nothing else does. The answer's shape is unchanged.

What changed: test/pull-merge-states-cache.test.ts now uses 100 open pulls instead of 50. It also asserts that the second, cached read of all 100 takes under 20 ms. The existing assertions still hold: the cached read spawns no git process, a push to one head recomputes only that pull (one rev-list, one merge-tree), and a base push recomputes every pull. The three tests in that file pass.

What I left out: I didn't time the full HTTP route. The test times pullMergeStates directly, which is where the merge phase spends its time. I also didn't run the whole check; the forge runs it on push.

Try it: bun test test/pull-merge-states-cache.test.ts

Closes #6197

Main already caches each pull's mergeable/conflicts answer by base and head oid (#6154). This pull only tightens its test to the issue's numbers.

What was already there: mergeReading in src/core/pulls.ts keys the cache by head and base oid. pullMergeStates reads both tips fresh from the ref files on every request, so a push to either side misses the cache and nothing else does. The answer's shape is unchanged.

What changed: test/pull-merge-states-cache.test.ts now uses 100 open pulls instead of 50. It also asserts that the second, cached read of all 100 takes under 20 ms. The existing assertions still hold: the cached read spawns no git process, a push to one head recomputes only that pull (one rev-list, one merge-tree), and a base push recomputes every pull. The three tests in that file pass.

What I left out: I didn't time the full HTTP route. The test times pullMergeStates directly, which is where the merge phase spends its time. I also didn't run the whole check; the forge runs it on push.

Try it: bun test test/pull-merge-states-cache.test.ts

I made both changes and pushed them. The three tests in test/pull-merge-states-cache.test.ts pass.

• 130 pulls: N is now 130, the number the issue names.
• Timing check: the test now times five cached reads and asserts the fastest is under 20 ms. One slow read on a busy machine no longer fails it. The zero-spawn assertion still sits beside it and is the hard gate.

The caching itself was already on main (#6154). This pull changes only the test.

To try it: bun test test/pull-merge-states-cache.test.ts

The full gate on land was red; the pull is open again. Red tests:

• the look > a real capture through the grant door, with /usr/bin/chromium
• the look > a dark capture is truly dark: the same page, light and dark, differs in its pixels
• a run that spends its budget > a run that finishes on its own gets no wrap-up

The gate's log: /api/v1/repos/trevato/forge/gates/1793094721101-8cc589e769e5/log

This pull changes one test file, test/pull-merge-states-cache.test.ts, and I can't tie the three red gate tests to it. I couldn't check them here.

What changed

• The cache already landed in #6154. This pull raises the test to 130 open pulls.
• It asserts that the best of five cached reads of pullMergeStates takes under 20 ms. The zero-Bun.spawn assertion stays as the hard gate.
• Following @juniper's second note, the redundant warm-up read before the timing loop is gone. The loop starts from first, the result of the uncached read.
• The three tests in that file pass locally.

The red gate tests

• The failures are "the look > a real capture through the grant door with /usr/bin/chromium", "the look > a dark capture is truly dark", and "a run that spends its budget > a run that finishes on its own gets no wrap-up". None of them touches src/core/pulls.ts or this test.
• The gate log URL returns not-found to my token, so I couldn't read the failures. Locally, the sandbox can't run them. A filtered run failed on the missing rg runtime and on an unrelated fixture that throws on load.
• Please look at those three on the gate machine. If they still fail on this push, send me the log.

Left out

• @juniper's first note asked me to time the HTTP route as well. I did not add that. The route test would need a full server and a seeded repository, and its time would mostly be request overhead, not the merge phase. pullMergeStates is the merge phase.

Try it

• bun test test/pull-merge-states-cache.test.ts

The cached read of 130 pulls is now bounded with expectBudget() instead of a raw millisecond number, and the title no longer states one.

• The bound: test/helpers/budget.ts supplies the budget helper. The test times the first, uncached read in the same run and takes the best of five cached reads. It asserts them with expectBudget(best, { ms: 20, against: uncached / 100 }), so a loaded machine slows both sides together.
• Title: it now reads "…does no git work and is cheap beside the first…".
• Zero-spawn assertion: the check that the cached read spawns no git is unchanged.
• Tests: test/pull-merge-states-cache.test.ts, test/budget.test.ts and test/flake.test.ts pass, and tsc --noEmit is clean. I didn't run the whole gate.
• Rebase: I could not rebase onto main, because that needs a force push and force pushes are refused. I merged origin/main into the branch instead and pushed that. The history carries a merge commit; if the queue needs a linear branch, a person has to rebase it.
• HTTP route: it is still untimed. I left a route-level check out because it would mostly measure request overhead, not the merge phase.

Try it with bun test test/pull-merge-states-cache.test.ts.

The full gate on land was red; the pull is open again. Red tests:

• no raw wall-clock budget in a test (#4429) > no test file holds a speed to a raw ms number

The gate's log: /api/v1/repos/trevato/forge/gates/1793099557402-2f1258cf4f7d/log

I couldn't reproduce the red gate test, so this push only brings the branch up to date with origin/main. no test file holds a speed to a raw ms number passes here on the current head, and test/pull-merge-states-cache.test.ts passes. My guess is the gate ran the head from before the expectBudget fix, but I couldn't confirm that. I couldn't read the gate log either. If the gate is still red on this head, send me the failing output.

What the test does

• test/pull-merge-states-cache.test.ts now reads 130 pulls.
• The zero-Bun.spawn assertion on the second read is the hard gate.
• The speed is bounded with expectBudget: the best of five cached reads must beat the same-run uncached read, divided by 100, against a 20 ms budget. No raw millisecond number is left in the file or its titles.

Left out

• I added no check of the HTTP route for GET pulls. It would mostly measure request overhead, and pullMergeStates is the merge phase the issue names.
• I did not rebase. Force pushes are refused, so the branch carries merge commits from main. If the queue wants linear history, a person has to rebase it.

Try it

• Run bun test test/pull-merge-states-cache.test.ts test/flake.test.ts.

Steward tick: this pull is red on its own merge with current main (gated alone, failed) and was held out of the landing queue so the others can land. Rebase on main, fix the failing test, push - then the hold comes off.

I added the route-level check for GET /api/v1/repos/alice/r/pulls with 130 open pulls. I did not remove the merge commits you asked about. The tests pass and the type check is clean. I only ran the two test files that cover this change (test/api-pulls-timing.test.ts and test/pull-merge-states-cache.test.ts), not the whole check.

Route check. The test in test/api-pulls-timing.test.ts seeds 130 open pulls and reads the list once cold. It then reads it five more times and takes the best merge phase from the Server-Timing header. That best time goes through expectBudget with a 20 ms cap, against the cold merge phase divided by 100. It also asserts that no merge-tree process is spawned while the cached reads run.

Rebase. I rebased onto main, but the branch had already been pushed, so the push was rejected. A force push is refused here, so I merged the remote branch back in and pushed that. The merge commit you wanted gone is still in the history; squashing it would take a person with merge rights.

Setup. alice and repo are now module-level variables set in beforeAll, because the new test needs them.