next-intl bare / (no cookie, no Accept-Language) drops the response (000) + leaks the request → server death

[proggeramlug]

Summary

A bare GET / to a next-intl app (no locale prefix) returns no response under perry (curl exit 28 / 000) where Node returns 307. It's deterministic, and each hit leaks a request/connection so that ~8 of them wedge the whole server.

Deterministic trigger (isolated)

Same standalone server (gscmaster, Next 16.1.1 + next-intl), single-threaded, warm:

request	perry	node
/en (explicit locale)	307 ✓	307
/ + Cookie: NEXT_LOCALE=de	307 ✓	307
/ + Accept-Language: de	307 → /de ✓	307 → /de
/ bare (no cookie, no Accept-Language)	000	307 (→ /, Set-Cookie: NEXT_LOCALE=en)
/ + Accept-Language: en (default locale)	000	307

The failing case is exactly the locale-detection / default path: no cookie and no Accept-Language. The winning cases (/en, /+cookie, /+AL) produce a byte-identical 307+Set-Cookie response — so it is not the response shape, redirect-to-self, absolute Location, or cookie (a minimal res.writeHead(307,{Location,Set-Cookie}); res.end(body) server handles all of those correctly under perry).

Localization

.next/server/chunks/[root-of-the-server]__…._.js middleware does:

new Negotiator({ headers: { "accept-language": e.get("accept-language") || void 0 } }).languages()

When Accept-Language is absent this passes undefined to Negotiator (the default-locale branch). On that path the async middleware() promise never settles under perry: no response is written (res.end() never called → the response oneshot is dropped → 000), and no error is logged. Each drop leaks the pending request; ~8 kill the server. A single hit fails but the server survives.

Headers.get("accept-language") for a missing header correctly returns null, and null || undefined === undefined (verified). So the drop is downstream — a lost async continuation in the default-locale middleware path (same class as #5989 "dynamic RSC render evaporates" and the streaming-race #6477), not the header read.

Impact

Any next-intl (or middleware-locale-detecting) app: the bare / root — the entry point — hangs for a client that sends no Accept-Language, and repeated hits take the server down.

[proggeramlug]

Further localization: config is localePrefix: "as-needed", defaultLocale: "en". The failing path is the default-locale branch — e.defaultLocale===s && "as-needed"===...localePrefix.mode → NextResponse.rewrite(...) / .next(...) (with a cookie-setting self-redirect for the no-cookie first hit), which is distinct from the non-default .redirect(/de) path that works. The async middleware runner (async()=>{try{ ...; await tu("/",nextUrl,null); ... }}) never reaches res.end() on that branch — no throw, no rejection. Pinpointing the exact dropped await needs middleware/async-flow instrumentation (no ready trace exists; PERRY_TRACE_THROW only covers throws). Same lost-continuation signature as #5989.

[proggeramlug]

Pinpointed with a new PERRY_TRACE_ASYNC diagnostic (logs each await-suspend on a pending promise + each settle; a suspend with no matching settle = lost continuation). Diffing the unmatched awaits of a working /en vs the dropped bare / isolates one lost await:

[ASYNC-SUSP #135 P=<promise>]   ← never settles for bare / (settles for /en)
  js_async_step_chain
  → router_server.js __70        ← the await site
  → router_server.js __41 → __73 → __31
  → start_server.js __70 → __42
  → js_node_http_server_process_pending → js_run_stdlib_pump → main

So a top-level await in Next's next/dist/server/lib/router-server.js (closure __70), in the request pipeline, awaits a promise that perry never resolves on the default-locale path — the async request handler never returns, so res.end() is never called (000 + leak). Next step: trace what creates/should-resolve that promise (its resolver is captured somewhere and never invoked for the self-redirect/default-locale branch).

[proggeramlug]

Deeper localization (PERRY_TRACE_ASYNC + creation-site tracking): the promise the router awaits is the continuation of an async fn in router-utils/resolve-routes.js (created via js_async_step_chain there). So Next's resolveRoutes async fn never completes on the default-locale path — it awaits something that never settles, so its result promise (awaited up the chain at router-server.js __70) never resolves → the request handler never returns → no res.end() (000 + leak). resolveRoutes is where Next runs the middleware (its awaits: fsChecker.getItem, serverResult.requestHandler, handleRoute, ensureMiddleware, checkTrue; it processes x-middleware-rewrite/x-middleware-next).

Finding the exact leaf await is currently blocked by a tool gap: the unmatched awaits bottom out on js_async_fn_result / js_promise_finally promises, which settle via adoption jobs / finally chains that bypass js_promise_resolve — so PERRY_TRACE_ASYNC's SETTLE hook (js_promise_resolve/reject only) reports false 'lost's. Next step: extend the settle detection (PR #6481) to hook the adoption-job + finally settle paths, then the true leaf (the real new Promise/subsystem promise whose resolver is never fired for the middleware rewrite/redirect branch) will stand out.

[proggeramlug]

Root cause found & fixed — PR #6487

The title ("middleware continuation drop") was a red herring. This is not an async/promise-continuation or promise-adoption bug (adoption propagation was verified sound). The real root cause:

Perry's Node http.request/http.get client auto-follows HTTP redirects; Node's never does.

Perry's Node http client is built on reqwest, whose default redirect::Policy follows up to 10 hops. Node's http.request/http.get never follow redirects (only fetch does).

How that hangs the bare / route

Traced end-to-end with routing probes in resolve-routes.js / router-server.js, compared against Node:

1. Bare / (no NEXT_LOCALE cookie) → next-intl middleware → x-middleware-rewrite: http://localhost/en (absolute; the rewrite host localhost differs from the request host 127.0.0.1). Identical under Node.
2. getRelativeURL sees different origins → keeps the rewrite absolute → resolve-routes.js returns early with an absolute parsedUrl → router-server.js calls proxyRequest (http-proxy over the Node http client). Identical under Node.
3. The proxied /en sub-request → middleware → 307 redirect back to /.
4. Divergence: Node's http client returns the 307 to http-proxy, which relays it to the client and stops (2 iterations). Perry's client follows the 307 to /, which re-rewrites to /en, re-proxies, 307s back to /… infinite loop (~73× /↔/en per request, then the response hangs — 000, connection leak).

Fix (PR #6487)

Disable redirect-following (reqwest::redirect::Policy::none()) on both Node-http client backends (perry-ext-http apply_node_proxy_policy for the external-http-client-pump path, and perry-stdlib's reqwest builder). fetch is unaffected.

Verified

After the fix, gscmaster bare / returns 307 Temporary Redirect with the correct x-middleware-rewrite / location / set-cookie headers — functionally identical to Node, no hang/loop. Added test-files/test_gap_http_client_no_redirect_follow.ts.

(Two minor cosmetic header residuals remain and are unrelated to this hang: perry sends content-length where Node sends transfer-encoding: chunked for the redirect body, and the link alternate-URL header uses localhost where Node uses the 127.0.0.1:PORT request host — a separate host-derivation quirk.)