Repository navigation
test: Next App Route dylib provider host hangs during cold start (route itself serves 21 requests) #8381
Description
Activity
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:
PASS: pinned Next 16.3.0 / React 19.2.4 lockfile PASS: production bundle exports routeModule.handle for /api/benchmark PASS: 21 production App Route requests PASS: pinned production Next App Route Node oracleSo 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 afterProvider ABI hash: …:run last line reached 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 1
line in the #8377 run is mykill, not an independent failure verdict, and
FIXTURE_EXIT=1reflects that kill. The 35 minutes of 0% CPU beforehand is the
observed 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".- changed the title
[-]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)[/+]on Aug 18, 2026
Symptom
tests/test_next_app_route_dylib.shhangs indefinitely. The provider host buildsand 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 gatestep failing (e.g. run 31993068277 onmain).Reproduced locally three times today, on three different trees:
main+ #8313main → js_wait_for_eventmain+ #8377main → run_microtasks → js_timer_tick → aux_has_active → js_node_http_server_has_activeBoth 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 moreinformative 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
.cargo/config.tomlfrom the invocation directory, not--manifest-path, sothe provider runtime lost
-C force-unwind-tables=yes. fix(test): make Next dylib provider build cwd-independent #8377 fixed it, and thehang persists unchanged afterwards.
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 walksup 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— establishwhether 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.