POST /apps/new names its Server-Timing phases (session, scaffold, repo, app, issue) and answers under 1 s #3718

POST /apps/new and POST /api/v1/apps now send a Server-Timing header that names session, scaffold, repo, app and issue.

Tests: the new tests in test/new-app-timing.test.ts pass. They make an app through each route, read the five phases, and check the whole POST stays under 1 s. A few neighbouring suites that exercise commits also pass. I didn't run the full bun test, and the tsc --noEmit run in my sandbox failed on a read-only tempdir, so I have no type-check result.

Phases: newApp takes an optional callback that reports each phase's duration. Both routes pass it through the existing notePhase helper. session is the session time the server already measures. When /apps/new retries a derived name as name-2, name-3 and so on, each retry adds its own phases to the header.

The app clash: the header already carries app;dur= for the total handler time. The new app phase, which is the time to create the app record, is a second entry with the same name, because the issue asks for that name. Server-Timing allows repeated names, but a reader looking for app will see two.

Scaffold was the slow part: on the test forge a first run showed about 216 ms of a 234 ms POST in scaffold, against about 12 ms for repo. It was running two git processes per file, about 40 in all. commitFiles in src/git/write.ts now hashes the blobs concurrently and stages them with a single update-index. A deletion still splits the batch so the order of changes holds. The path_conflict refusal still happens, and it names the path git reports, falling back to the first file in the batch. I didn't re-measure after the change, so I can't give a new scaffold time.

Not done: I didn't switch to writing the whole commit with fast-import or mktree. The batching keeps the existing safety checks, and the POST was already well under 1 s.

To try it: curl -si -X POST -H "origin: $URL" -H "authorization: Bearer …" -d '{"name":"x"}' $URL/api/v1/apps and read the server-timing header.

Closes #3667

POST /apps/new and POST /api/v1/apps now send a Server-Timing header that names session, scaffold, repo, app and issue.

Tests: the new tests in test/new-app-timing.test.ts pass. They make an app through each route, read the five phases, and check the whole POST stays under 1 s. A few neighbouring suites that exercise commits also pass. I didn't run the full bun test, and the tsc --noEmit run in my sandbox failed on a read-only tempdir, so I have no type-check result.

Phases: newApp takes an optional callback that reports each phase's duration. Both routes pass it through the existing notePhase helper. session is the session time the server already measures. When /apps/new retries a derived name as name-2, name-3 and so on, each retry adds its own phases to the header.

The app clash: the header already carries app;dur= for the total handler time. The new app phase, which is the time to create the app record, is a second entry with the same name, because the issue asks for that name. Server-Timing allows repeated names, but a reader looking for app will see two.

Scaffold was the slow part: on the test forge a first run showed about 216 ms of a 234 ms POST in scaffold, against about 12 ms for repo. It was running two git processes per file, about 40 in all. commitFiles in src/git/write.ts now hashes the blobs concurrently and stages them with a single update-index. A deletion still splits the batch so the order of changes holds. The path_conflict refusal still happens, and it names the path git reports, falling back to the first file in the batch. I didn't re-measure after the change, so I can't give a new scaffold time.

Not done: I didn't switch to writing the whole commit with fast-import or mktree. The batching keeps the existing safety checks, and the POST was already well under 1 s.

To try it: curl -si -X POST -H "origin: $URL" -H "authorization: Bearer …" -d '{"name":"x"}' $URL/api/v1/apps and read the server-timing header.

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

I fixed the type-check failure by removing the duplicate route_timing imports that the merge from main left behind. I couldn't run tsc here because bun install can't write to its temp directory in this sandbox. The fix is pushed, so the forge's check will be the first type-check of it.

• Cause: src/http/api.ts and src/web/pages/apps.ts each imported notePhase and takeSessionTime twice.
• Fix: I deleted the extra import in src/http/api.ts (around line 443) and the extra one at the top of src/web/pages/apps.ts. Each file now imports from route_timing once.
• Tests: the timing test files (test/timing.test.ts, 106 tests) pass. I didn't run the rest of the suite.

Both review points are fixed and pushed. The timing test, test/edits-security.test.ts and the git suites pass (55 pass, 14 skip, 0 fail). I couldn't run tsc here, because bun can't write its tempdir in this sandbox and node_modules has no tsc binary. I haven't tried a fresh signup on the preview.

• Test gap: expectPhases in test/new-app-post-timing.test.ts now counts entries instead of using find. Each of session, scaffold, repo and issue must appear exactly once. app; must appear twice, the total-handler entry plus the phase. Deleting any lap(...) or noting session twice now turns the test red.
• ARG_MAX: commitFiles in src/git/write.ts now flushes the update-index batch once it reaches 200 entries or about 256 KB of argument bytes. A request with up to 1,000 long paths therefore runs several bounded update-index calls, not one oversized argv. I didn't add a test for the flush threshold; the existing git suites pass with it.

The unverified-account 422 on a fresh preview signup is existing behaviour, and I left it alone.

commitFiles now hashes blobs through a fixed pool of 4 workers, so one request can no longer queue up to 1,000 hash-object spawns on the shared git semaphore (gitGate).

• Fix: the pool size is the exported constant HASH_POOL in src/git/write.ts. The update-index batching is unchanged. A commit now holds at most 4 permits at once, and the 20-file scaffold still hashes in parallel.
• Test: test/commit-fanout.test.ts commits 32 files and asserts the gate's peak stays at or below HASH_POOL and that nothing waits behind the commit. With the pool bypassed it fails, so it would catch a regression.
• Checks: that test, test/git.test.ts and test/chain-timing.test.ts pass. I couldn't run bun x tsc --noEmit here because bun can't write to its tempdir in this sandbox, so the type check is unverified; the forge's check will cover it.
• Left alone: the duplicate app;dur= entry in Server-Timing. The issue named the phase app. I agree a rename to record or enable would be clearer, but I'm leaving it for a follow-up as you suggested.