fix(web-e2e): probe a fresh url each poll, and stop blaming next dev for answering

[choraria]

Why

CI is red on main at 7d07827 in the web-e2e job. #783 touched only the IndexNow scripts and .gitleaksignore — apps/web and packages/ are byte-identical to the green run before it (git diff 74e921ed 7d078279 -- apps/web packages/ is empty). This is the boot probe, not the product.

What the failing run actually shows

✓ Ready in 352ms
  GET /dev-session 307 in 1009ms
○ Compiling /[...legacy] ...
  GET /org/…/payload 404 in 4.5s   (next.js: 4.1s)
  GET /org/…/payload 404 in 108ms  (next.js: 10ms)
  … 542 of them, then "next dev did not answer … within 180000ms"

The server answered every probe, promptly, for the entire three minutes.

next dev began serving before its scan of src/app reached the deepest route, so the catch-all (app)/[...legacy] claimed the url, compiled, and 404'd. Every later poll for that same url came back in ~2ms of Next time, with no second Compiling line — a cached match, not a fresh resolution. The green run on the identical tree asked once, after the table was complete, and got its 307 on the first request. Which side of that race a run lands on is the only difference between them.

The fix

Re-asking one constant url cannot recover: the loop re-sends exactly the url whose resolution already went to the catch-all. probeUrlFor now mints a fresh uuid per dynamic segment on every call, so each poll is a url next dev has never resolved — matched against the route table as it stands at that moment, which is the question the probe means to ask.

The uuid is generated inside the function rather than accepted as a parameter, so a caller cannot hoist it out of the poll loop and quietly restore the constant. The route (the src/app walk) is still hoisted; only the url is per-poll.

Second change: the timeout said next dev did not answer for both failure modes, and in the one that actually happens that is a lie. It cost this investigation a trip through process spawning, port binding and the database before the logs revealed a healthy server the whole time. It now distinguishes the two and reports what the last probe saw.

Verification

• deepest-route unit tests 18/18. The new distinctness test is RED before this change — 20 calls produced 1 unique url (expected 1 to be 20).
• apps/web e2e 25/25, run three times.
• Root pnpm typecheck 33/33 (@webhook-co/web a fresh cache miss), pnpm lint 639 pass, prettier clean.

Honest caveat for the reviewer

The stickiness mechanism is inferred from the CI logs (single Compiling line, 4.1s → 2ms of Next time, no recovery in 180s), not reproduced locally. I could not synthesise the window — it needs the route table to be incomplete at t0 and complete at t1 with no intervening file event, and any file change I make to force it invalidates the very cache under test. My first attempt at a proof (moving the route dir aside and back) was inconclusive for exactly that reason, and I discarded it rather than count it as evidence.

What is certain: the server was healthy and answering throughout, the deepest route never entered its table, and re-asking one constant url demonstrably cannot recover. A fresh url per poll is correct under either mechanism and cannot be worse than a constant one — but it is CI, over time, that confirms the flake is gone.

Draft because of that caveat.

🤖 Generated with Claude Code

https://claude.ai/code/session_019LhaMQFjLyhrrMxs1sxTZV