A map's ask-to-live medians come from one batched read: `asktolive` under 50 ms for trevato/forge #6186

askToLiveFor now takes about 5 ms on a fixture of 400 merged pulls across 8 pillars. Before the change, the same query took about 31 ms on that fixture. I haven't measured the real 1.2 s on trevato/forge. bun test passes for the new test and test/pillars.test.ts. The type check only reports a missing bun types file, so it checked nothing. I did not run the rest of the suite.

Cause. The merged pulls and their issues were already read in a fixed number of queries. The slow part was the deploy lookup in askToLiveByPillar (src/core/pillars.ts). It read every successful production deploy the repository had ever made, then matched them to pulls in JavaScript. SQLite chose to scan run first, so the cost grew with the repository's whole deploy history, not with the week's pulls.

Change. The deploy lookup now starts from the window's merged pulls and reads their deploy_pull rows through the existing deploy_pull_issue index. A CROSS JOIN makes SQLite use that order. The ids go in chunks of 400, so it is still a fixed number of queries. Results are re-sorted by time so the "first deploy that carried it" logic gives the same answer.

Sealed issues. Nothing about the filter changed. The user filter still applies when the pulls and issues are read, and the deploy lookup only sees pulls that passed it.

Tests. test/ask-to-live-batched.test.ts has two tests:

• Same answer: it compares the median and slowest per pillar with a one-pull-at-a-time reference written in the test. The test checks this for a writer who sees sealed issues and for an anonymous viewer who doesn't. The fixture has sealed asks, pulls that never went live, and 5,000 noise runs.
• Speed: it asserts the 400-pull case runs in under 50 ms. It uses the repo's expectBudget helper, which loosens the limit when the machine is loaded.

Left out. The reference lives in the test, not in src/, so the old implementation is not kept in the tree. I did not touch the other costs in the map request (the 1.6 s total is more than ask-to-live); this fixes the asktolive part only.

To try. Run bun test test/ask-to-live-batched.test.ts. Then compare asktolive;dur in the Server-Timing header of GET /api/v1/repos/trevato/forge/map on the preview with the 1163.7 ms measured on production.

🤖 Generated with Claude Code

Closes #6175

askToLiveFor now takes about 5 ms on a fixture of 400 merged pulls across 8 pillars. Before the change, the same query took about 31 ms on that fixture. I haven't measured the real 1.2 s on trevato/forge. bun test passes for the new test and test/pillars.test.ts. The type check only reports a missing bun types file, so it checked nothing. I did not run the rest of the suite.

Cause. The merged pulls and their issues were already read in a fixed number of queries. The slow part was the deploy lookup in askToLiveByPillar (src/core/pillars.ts). It read every successful production deploy the repository had ever made, then matched them to pulls in JavaScript. SQLite chose to scan run first, so the cost grew with the repository's whole deploy history, not with the week's pulls.

Change. The deploy lookup now starts from the window's merged pulls and reads their deploy_pull rows through the existing deploy_pull_issue index. A CROSS JOIN makes SQLite use that order. The ids go in chunks of 400, so it is still a fixed number of queries. Results are re-sorted by time so the "first deploy that carried it" logic gives the same answer.

Sealed issues. Nothing about the filter changed. The user filter still applies when the pulls and issues are read, and the deploy lookup only sees pulls that passed it.

Tests. test/ask-to-live-batched.test.ts has two tests:

• Same answer: it compares the median and slowest per pillar with a one-pull-at-a-time reference written in the test. The test checks this for a writer who sees sealed issues and for an anonymous viewer who doesn't. The fixture has sealed asks, pulls that never went live, and 5,000 noise runs.
• Speed: it asserts the 400-pull case runs in under 50 ms. It uses the repo's expectBudget helper, which loosens the limit when the machine is loaded.

Left out. The reference lives in the test, not in src/, so the old implementation is not kept in the tree. I did not touch the other costs in the map request (the 1.6 s total is more than ask-to-live); this fixes the asktolive part only.

To try. Run bun test test/ask-to-live-batched.test.ts. Then compare asktolive;dur in the Server-Timing header of GET /api/v1/repos/trevato/forge/map on the preview with the 1163.7 ms measured on production.

🤖 Generated with Claude Code

The speed test now fails against the old query and passes against the new one, as Sentinel asked. bun test test/ask-to-live-batched.test.ts test/pillars.test.ts passes (16 tests).

• Fixture (test/ask-to-live-batched.test.ts): it now adds 40,000 successful production deploys inside the window, each with a deploy_pull row for a pull merged before it. This is the long deploy history Sentinel pointed out was missing.
• Result: with the base src/core/pillars.ts restored, the 50 ms test fails at about 78 ms. With the fix it runs in about 5 ms. I did not add the EXPLAIN QUERY PLAN assertion; the timing test already fails without the change.
• Re-sort (src/core/pillars.ts): removed, as Sentinel suggested. Each pull id lands in exactly one chunk, and each chunk is already ordered by time then run id, so the lists are already in order. That also keeps the run-id tiebreak.

The fix itself is unchanged. The deploy lookup starts from the window's merged pulls and reads their deploy_pull rows through deploy_pull_issue, in chunks of 400. The sealed-issue scope still applies when the pulls are read.

The preview has no repositories, so the asktolive improvement can't be seen there. The test is the only proof until this reaches trevato/forge.

🤖 Generated with Claude Code

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
• no raw wall-clock budget in a test (#4429) > no test file holds a speed to a raw ms number [423.05ms] [shard 708]

I fixed the red gate test. test/flake.test.ts, test/ask-to-live-batched.test.ts and test/pillars.test.ts all pass (44 tests).

• The failure: the "no raw wall-clock budget" check flags a test title that promises a raw millisecond number, and mine said "answer in under 50 ms". The title now reads "answer within the budget". The assertion is unchanged and still goes through expectBudget at 50 ms.
• Juniper's tidy-ups:

- The long doc comment in src/core/pillars.ts is wrapped. - The test header now cites #6186. - The three function-local CHUNK = 400 constants are now one module constant. That changes the two older query paths as well, though their behaviour is the same.

The check on production is still outstanding. Once this lands, someone should read asktolive;dur in the Server-Timing header of GET /api/v1/repos/trevato/forge/map and note it on #6175. I can't see that from here.

🤖 Generated with Claude Code