A proxied app response names the forge's own time in Server-Timing, beside the app's phases #8179

A proxied app response now keeps the app's Server-Timing entries and appends the forge's own phases after them, but I have no preview curl for the pull description. The new test file passes (3 tests), as do the related proxy and toolbar tests (52 tests), and tsc and the gate are clean. I didn't look up this pull's preview URL or curl it, so the curl you asked for is not here. The one curl I ran was against production, which is still the old build and shows only db;dur=0.1, app;dur=1.5.

What changed

• Phases: src/apps/proxy.ts appends forge-route, forge-wake, forge-upstream and forge-rewrite.

- forge-route runs from when the server took the request to the app being ready, minus the wake. - forge-wake is 0 when the app was already awake. - forge-upstream runs until the app's headers arrive. - forge-rewrite appears only when the pill was injected.

• Names and contents: the forge- prefix keeps the names from colliding with the app's db/app. The header carries durations only, with no hosts, ids or user names.
• Supporting change: src/core/route_timing.ts gains a small startedAt(request) getter.
• Tests: test/apps-proxy-timing.test.ts checks three things.

- A fake upstream sleeps 300 ms and returns db;dur=0.1, app;dur=1.1; the test sees forge-upstream ≥ 300 and the app's entries intact at the front. - The same test checks the header contains only durations and no app name, and that forge-rewrite appears on an HTML page. - A sleeping env shows forge-wake > 0.

Not covered: the early-exit answers (the "app stopped answering" page, a refused grant, a WebSocket upgrade) don't get the forge phases. Only responses relayed from an app do.

Where the 6–11 s goes: I can't tell from here. Production's header shows the app spending about 1 ms, so the time sits outside the app. Once this deploys, forge-wake will show a cold start and forge-route will show the forge's own lookup. If both are small and the first byte is still slow, the delay is before the request reaches the forge, in the network or edge.

Try it: curl -sI https://lab--<this pull's number>--forge-trevato-apps.open-platform.sh/healthz | grep -i server-timing. Expect db;…, app;…, forge-route;dur=…, forge-wake;dur=…, forge-upstream;dur=….

Closes #8155

A proxied app response now keeps the app's Server-Timing entries and appends the forge's own phases after them, but I have no preview curl for the pull description. The new test file passes (3 tests), as do the related proxy and toolbar tests (52 tests), and tsc and the gate are clean. I didn't look up this pull's preview URL or curl it, so the curl you asked for is not here. The one curl I ran was against production, which is still the old build and shows only db;dur=0.1, app;dur=1.5.

What changed

• Phases: src/apps/proxy.ts appends forge-route, forge-wake, forge-upstream and forge-rewrite.

- forge-route runs from when the server took the request to the app being ready, minus the wake. - forge-wake is 0 when the app was already awake. - forge-upstream runs until the app's headers arrive. - forge-rewrite appears only when the pill was injected.

• Names and contents: the forge- prefix keeps the names from colliding with the app's db/app. The header carries durations only, with no hosts, ids or user names.
• Supporting change: src/core/route_timing.ts gains a small startedAt(request) getter.
• Tests: test/apps-proxy-timing.test.ts checks three things.

- A fake upstream sleeps 300 ms and returns db;dur=0.1, app;dur=1.1; the test sees forge-upstream ≥ 300 and the app's entries intact at the front. - The same test checks the header contains only durations and no app name, and that forge-rewrite appears on an HTML page. - A sleeping env shows forge-wake > 0.

Not covered: the early-exit answers (the "app stopped answering" page, a refused grant, a WebSocket upgrade) don't get the forge phases. Only responses relayed from an app do.

Where the 6–11 s goes: I can't tell from here. Production's header shows the app spending about 1 ms, so the time sits outside the app. Once this deploys, forge-wake will show a cold start and forge-route will show the forge's own lookup. If both are small and the first byte is still slow, the delay is before the request reaches the forge, in the network or edge.

Try it: curl -sI https://lab--<this pull's number>--forge-trevato-apps.open-platform.sh/healthz | grep -i server-timing. Expect db;…, app;…, forge-route;dur=…, forge-wake;dur=…, forge-upstream;dur=….

I've pushed fixes for all five points, and the preview still can't show the header. The tests, tsc and the gate pass locally. I didn't re-run the forge's check or look at the preview after this push.

1. Preview shows only the app's entries. I agree with your reading. A preview is an app run by this repo, and the proxy that answers for it is the forge running main. A preview of this branch therefore can't show forge-* entries until the change merges and production runs it. The proof is test/apps-proxy-timing.test.ts, which sends real requests through proxyApp to a fake upstream. It shows:

- forge-upstream ≥ 250 beside the app's own db/app entries, which stay first. - forge-route, and forge-wake of 0. - forge-rewrite on an HTML page. - A header with only durations.

1. Timing and speed.

- The upstream bound is now ≥ 250 against the 300 ms sleep. - I dropped the real-sweeper sleeping test. withForgePhases is exported and tested directly, with the app's header present, absent and empty. - forge-wake > 0 has no end-to-end test any more, which I'm flagging because the issue asked for one.

1. Early exits. The "app stopped answering" page now carries forge-route, forge-wake and forge-upstream. It does so both when the fetch fails and when the body read fails after a rewrite starts.

- A wake that ends in a refused door carries route and wake. - The /__forge/* pages, the WebSocket upgrade, and the unavailable answer from a failed WebSocket connect don't carry them. docs/APPS.md says so.

1. README. A short paragraph on reading the entries is in the README, and a longer one is in docs/APPS.md.
2. Test and scope. withForgePhases has its own test now. Appending the forge's phases to a proxied response is the issue's own first checkbox, so I think it's in scope. I can't tell what "not a pipeline item" refers to, so tell me if you meant something else.

I still can't say where the 6–11 s goes. Once this is on production, forge-wake will show a cold start, forge-route will show the forge's own lookup, and forge-upstream will show the app. If all three are small, the time went before the request reached the forge.

When the forge relays an app's response, the Server-Timing header now keeps the app's own entries and adds the forge's time after them: forge-route, forge-wake, forge-upstream and, when the pill was written into the page, forge-rewrite. Each is a duration in milliseconds, nothing else. Issue #8155 asked for this feature by name; it is not a pipeline item.

What to look at

• One writer (src/apps/proxy.ts): the second writer is gone. The forge's phases are recorded with notePhase under forge- names and written by the existing withPhases. withPhases now adds to the header instead of replacing it, so the app's entries stay first. The forge- prefix keeps them from clashing with the app's names or the server's own route.
• Refused answers carry no timing: sign-in redirect, not found, not running and the other refusals. The wake runs before the access check, so its time would tell someone who may not read the app whether it was asleep. docs/APPS.md says this.
• The "app stopped answering" page carries forge-route, forge-wake and forge-upstream, both when the app never answers and when the body breaks off partway.
• Docs: the README paragraph moved up beside the paragraph that introduces apps and previews.
• Outside src/apps/: the only change is the startedAt export in src/core/route_timing.ts.

Proof: the tests. The preview can't show the forge-* entries, because the proxy answering previews is the forge on main. test/apps-proxy-timing.test.ts is the proof:

• A slow app keeps its own entries, and forge-upstream is at least 250 ms.
• A pill-rewritten page names forge-rewrite.
• A request that wakes the app gets forge-wake of at least 140 ms. The wake is stubbed on the runtime to take 150 ms and does not use the sweeper.
• A refused answer after a wake has no forge- entries.
• A fake upstream on a raw socket triggers "stopped answering" two ways, both carrying the forge's phases: closing without replying, and closing partway through a body.

I checked the mid-body test by removing that path's header write; the test then fails.

Checks run

• bun scripts/gate.ts and bun x tsc --noEmit pass.
• scripts/fast.ts named 1,322 of 1,809 test files (about 114 minutes), so I ran the proxy and app tests myself instead: apps-proxy-timing, apps-door, toolbar-side, apps-sleep, private-app and app-read-timing. All 52 pass.
• Not run: the full suite (the forge runs it on push) and design lint (src/web/ is untouched).

🤖 Generated with Claude Code