Repository navigation
test: Next App Route dylib provider host hangs during cold start (route itself serves 21 requests) #8381
Description
Symptom
tests/test_next_app_route_dylib.sh hangs indefinitely. The provider host builds
and links fine, prints its ABI hash, and then never serves a request — the
harness waits until it is killed. CI shows this as the
Production App Route provider gate step failing (e.g. run 31993068277 on
main).
Reproduced locally three times today, on three different trees:
| tree | stack at hang |
|---|---|
main + #8313 |
main → js_wait_for_event |
main + #8377 |
main → run_microtasks → js_timer_tick → aux_has_active → js_node_http_server_has_active |
Both are the same shape: 0.0% CPU, no child process, parked in the event-loop
pump, last output Provider ABI hash: …. The second stack is the more
informative one — the host is asking whether the HTTP server has active handles
and getting an answer that keeps it idle, so it never begins serving.
What it is NOT
- Not [test] test_next_app_route_dylib.sh is silently cwd-sensitive: run from outside the repo, the provider runtime loses -C force-unwind-tables and fails 25 minutes later naming the wrong cause #8258 (cwd-dependence). That was a real, separate defect — Cargo reads
.cargo/config.tomlfrom the invocation directory, not--manifest-path, so
the provider runtime lost-C force-unwind-tables=yes. fix(test): make Next dylib provider build cwd-independent #8377 fixed it, and the
hang persists unchanged afterwards. - Not a stray-
node_modulesresolution problem. A worktree placed under
/private/tmpdoes fail differently and fatally
(JavaScript runtime (V8) support has been removedon
/private/tmp/node_modules/@opentelemetry/api, because Node resolution walks
up out of the fixture), but from a normal worktree root that import is only
Warning: Could not resolveand the build proceeds to the hang above.
Why it matters
This is the acceptance gate for the #8034/#8040 production Next App Route, and it
is the natural end-to-end check for object-layout and ABI changes — exactly the
class that has silently broken split modules before (#8204 → #8228/#8241). While
it hangs, layout-changing PRs lose their most realistic verification: #8313 (the
40-byte header) had to fall back to the gap suite for that reason.
Suggested starting point
js_node_http_server_has_active / stdlib_pump::aux_has_active — establish
whether the server handle is registered at all in the dylib-provider
configuration, or whether it is registered but reports inactive so the pump never
dispatches it.
Activity
proggeramlug commentedon Aug 18, 2026
Correcting my own report above. I wrote "never serves a request". That is
wrong, and it matters because it points at the wrong place.
The harness's earlier phases all pass, identically in both reproductions:
So the route logic, the production bundle, and 21 real App Route requests are
fine. The hang is specifically in the dylib provider-host cold start, which
is the phase right after
Provider ABI hash: …:main+ #8313Provider ABI hash: f41325…then hangmain+ #8377Provider ABI hash: 9e85ab…then hangBoth stall there with the host at 0.0% CPU, no child process, parked in the
event-loop pump — the second sample showing
run_microtasks → js_timer_tick → aux_has_active → js_node_http_server_has_active.One more caveat on the evidence: the
provider host exited during cold start 1line in the #8377 run is my
kill, not an independent failure verdict, andFIXTURE_EXIT=1reflects that kill. The 35 minutes of 0% CPU beforehand is theobserved fact; the exit code is mine.
Revised starting point: not "the server never comes up" in general, but "the
dylib provider host's HTTP server never registers as active during cold start,
while the same route serves fine through the non-provider path in the phase
immediately before".
[-]test: Next App Route dylib gate hangs after the provider ABI hash, never serves[/-][+]test: Next App Route dylib provider host hangs during cold start (route itself serves 21 requests)[/+]