/search?q=a answers under 300 ms on a fixture of production's size, pinned by a test that reads its Server-Timing phases #11177

A new test sends /search?q=a to a forge of production's size, signed out and signed in. It fails if the Server-Timing app phase, or any named phase, reaches 300 ms, or if the request runs more than 40 SQL statements. The issue search now reads a bounded number of rows per repository instead of every matching row.

Fixture (test/search-production-size.test.ts): the production fixture from test/helpers/big-forge.ts, which is:

• 9,000 issues and 9,000 pulls in one repository;
• 60,000 runs, 120,000 comments and 400,000 events.

On top of that it adds 1,000 more repositories, a mix of public and private, under two owners. Every title, repository name and description contains an a, so the one letter matches every row: the worst case. The fixture's PRODUCTION sizes say they are "roughly the forge's own database in November 2026". I couldn't count production's repositories with my access, so 1,000 is a guess meant to be above it.

Fix in the search read (src/core/search.ts, searchLocalIssues): the old query ran over repo_id IN (…), sorted by updated_at, then applied the limit. For q=a that sorted all 18,000 matches to keep 20. It is now one UNION ALL part per repository. Each part walks the issue_repo_updated index newest first with its own LIMIT, and the parts are merged and cut to the limit again. So rows read are capped at the limit per repository, and the number of parts is capped at MAX_SEARCH_REPOS. Nothing is cached; results are the same newest-first page as before.

The plan test in test/search.test.ts now also checks for one index walk per repository. It fails on the old query (1 walk where 2 are expected).

Phases before and after, measured locally on the fixture (this branch's base already has #11125, which stopped grepping code for one letter):

Production today, signed out: app;dur=30.6, … issues;dur=4.8 …. Releases 0.7.522 and 0.7.524 took 1,779 ms and 2,615 ms before #11125.

Left out:

• Issue search still only looks in the 50 newest visible repositories (MAX_SEARCH_REPOS), ordered by id. This fixture had to give its extra repositories older ids so the forge's own repository stayed in that window. That limit was already there; this pull leaves it alone.
• A query that matches almost nothing still walks each repository's index in full, the same as before.
• I couldn't call the keep_plan tool from this session, so the issue has no plan.

Checks run: bun scripts/gate.ts and bun x tsc --noEmit both pass. scripts/fast.ts named 1,735 test files for this change, too many to run here, so I ran the search, sealed, API, MCP and CLI search tests by hand: 194 pass across 28 files.

To try: bun test test/search-production-size.test.ts prints each request's Server-Timing.

🤖 Generated with Claude Code

Closes #11168

A new test sends /search?q=a to a forge of production's size, signed out and signed in. It fails if the Server-Timing app phase, or any named phase, reaches 300 ms, or if the request runs more than 40 SQL statements. The issue search now reads a bounded number of rows per repository instead of every matching row.

Fixture (test/search-production-size.test.ts): the production fixture from test/helpers/big-forge.ts, which is:

• 9,000 issues and 9,000 pulls in one repository;
• 60,000 runs, 120,000 comments and 400,000 events.

On top of that it adds 1,000 more repositories, a mix of public and private, under two owners. Every title, repository name and description contains an a, so the one letter matches every row: the worst case. The fixture's PRODUCTION sizes say they are "roughly the forge's own database in November 2026". I couldn't count production's repositories with my access, so 1,000 is a guess meant to be above it.

Fix in the search read (src/core/search.ts, searchLocalIssues): the old query ran over repo_id IN (…), sorted by updated_at, then applied the limit. For q=a that sorted all 18,000 matches to keep 20. It is now one UNION ALL part per repository. Each part walks the issue_repo_updated index newest first with its own LIMIT, and the parts are merged and cut to the limit again. So rows read are capped at the limit per repository, and the number of parts is capped at MAX_SEARCH_REPOS. Nothing is cached; results are the same newest-first page as before.

The plan test in test/search.test.ts now also checks for one index walk per repository. It fails on the old query (1 walk where 2 are expected).

Phases before and after, measured locally on the fixture (this branch's base already has #11125, which stopped grepping code for one letter):

Production today, signed out: app;dur=30.6, … issues;dur=4.8 …. Releases 0.7.522 and 0.7.524 took 1,779 ms and 2,615 ms before #11125.

Left out:

• Issue search still only looks in the 50 newest visible repositories (MAX_SEARCH_REPOS), ordered by id. This fixture had to give its extra repositories older ids so the forge's own repository stayed in that window. That limit was already there; this pull leaves it alone.
• A query that matches almost nothing still walks each repository's index in full, the same as before.
• I couldn't call the keep_plan tool from this session, so the issue has no plan.

Checks run: bun scripts/gate.ts and bun x tsc --noEmit both pass. scripts/fast.ts named 1,735 test files for this change, too many to run here, so I ran the search, sealed, API, MCP and CLI search tests by hand: 194 pass across 28 files.

To try: bun test test/search-production-size.test.ts prints each request's Server-Timing.

🤖 Generated with Claude Code