nextjs: dynamic RSC render evaporates silently with a clean async graph after expected manifest ENOENTs (post-#5988 wall for 8/8)

[proggeramlug]

Summary

Follow-up to #5941 / PR #5988. With the #5941 async-step deadlock class eliminated (no parked machines, all promises settle, rejections propagate), the 3 request-time dynamic RSC routes (/posts/[id], /fetcher, /plain) still return 0 bytes — but the failure mode is now completely different: the render evaporates silently with a clean async graph. This is the remaining blocker for 8/8 on the Next.js 16 App Router standalone matrix.

Ground truth (measured on PR #5988's branch, /plain)

• Stuck-machine dump (PERRY_STUCK_DUMP=1, toolkit on branch fix/async-step-per-activation-identity-5941): zero live async-step machines during the hang. Nothing is parked. Every machine's result settles.
• Request-window rejection log: the boot-time /_document + /_app PageNotFoundError rejections propagate and are caught (expected — same probes exist in node; this app has no pages router).
• Request-window sync-throw log (armed via /tmp/perry-arm-throw right before the curl): exactly two throws, both expected and caught-in-node:
  • ENOENT ... .next/server/subresource-integrity-manifest.json
  • ENOENT ... .next/dynamic-css-manifest
    Neither file exists in the build (optional manifests); node throws + catches the same loads and renders fine.
• After those two throws: nothing. No further throws, no rejections, no machines, no timers, no response write. The HTTP request never completes (curl 000 after any timeout).

What this is NOT

• Not the transform: async-step render state machines lose per-activation identity at scale — Next.js dynamic RSC deadlock (last 3/8 SSR routes) #5941 deadlock (that's gone — measured).
• Not makeHangingPromise/abort-chain parking (no pending promises remain at all).
• Not the manifest ENOENTs being uncaught (they're caught; execution continues past them).

Hypotheses for whoever picks this up

1. The render errors out synchronously somewhere after the manifest loads and Next's error-recovery path (renderErrorToResponse → pages-router /_document fallback → also missing) gives up without writing a response — check whether node writes a 500 there vs Perry writing nothing, and what the primary render error is (the known Failed to install Date class extension + cacheComponents dynamic-detection interaction is a candidate — boot prints that warning under Perry only).
2. A response/stream plumbing divergence: the App Router render may complete but pipeToNodeResponse/flush never runs. Instrument the res.write/end path in perry-ext-http next.

Repro

Standalone Next.js 16 App Router build at /tmp/nx-mine2 (internal box), oracle /tmp/nx-oracle3; compile server.js with PR #5988's branch, boot with the PERRY_ALLOW_* trio, curl /plain. Diagnostic toolkit + armed throw/rejection loggers on branch fix/async-step-per-activation-identity-5941.

References

#5941 (the eliminated deadlock class), PR #5988, #5932, #5437 (tracking).

[proggeramlug]

Deep-dive session update — the "silent render evaporation" turned out to sit behind a chain of five compiler/runtime bugs that the #5988 fixes had newly made reachable. All five are fixed on branch fix/5989-global-builtin-assignment (pushed, 6 fix commits + env-gated diag commit), each with a node-identical minimal repro:

1. Strict-mode assignment to an existing global builtin threw ReferenceError instead of writing the global property (spec PutValue). This is exactly how Next 16's cacheComponents installs its Date extension (Date = createDate(Date) in strict CJS) — the install failed at every boot ("Failed to install Date class extension") and dynamic-IO clock detection never armed. New runtime helper js_global_assign_existing_or_throw + both HIR assignment arms.
2. The reified Reflect.construct VALUE was a no-op stub returning undefined — the extension calls it through a captured binding (const construct = Reflect.construct). Plus Reflect.construct(Date, args, newTarget) fell to the generic construct tail (unbranded "Invalid Date"), plus identify_global_builtin_constructor broke the moment the global was reassigned (its name recovery walked globalThis). All three fixed.
3. Compiled zod's class layout miscompiled (webpack arrow factory, class ZodType { _refinement(){ return new ZodEffects({...}) } } … class ZodEffects extends ZodType {}): the forward sibling-class capture read a stub local that never received the class value, so Next's config-schema validation threw "undefined is not a constructor" at boot the moment it became reachable. Fixed (stub-id reuse in body_stmt.rs + the RegisterClassCaptures refresh pass extended to ARROW bodies).
4. CJS export getters registered before a heritage class (Object.defineProperty(exports, "Sub", { get: () => Sub }) above class Sub extends _suffix.Base) captured the class-name local by value while still undefined — RSCPathnameNormalizer (and router-utils/filesystem) constructed undefined at boot. Fixed: forward-referenced heritage-class names pre-register as boxed locals like forward-captured lets (narrowed to heritage classes only — a plain class's value is its static ClassRef, and pre-registering a local broke self-referential static initializers like render-result.js's static #_ = this.EMPTY = new RenderResult(...)).
5. SIGSEGV in shape_is_url_search_params (fix(runtime): #5961 — URLSearchParams methods reachable through dynamic access #5964 code): the receiver was header-validated but keys_array was dereferenced raw — first request killed the server. Gated with the same try_read_gc_header check (Segmentation fault.: console.log(dayjs(1749820051142).format()); #5429/fix(runtime): validate spread sources; full handle band + no type-pun on the dynamic set path #5943 family).

Validation: gap spot-check 9/9 byte-identical, perry-hir 222/222, perry-transform 48/48, promise 53/53 (one pre-existing GC-alloc flake, reproduced on pristine main), new + existing integration tests green, fmt/GC-audit/addr-audit/file-size gates pass.

Important reframe: the old "statics pass" result rode on silently degraded config — config-schema validation used to crash (caught), so Next fell back to defaults and served through the simple pipeline. With validation now working, the app runs the REAL cacheComponents pipeline, which exercises much deeper machinery. Current frontier on that pipeline: requests reach base-server closure __162 and die/hang with an oscillating signature — one build shows a not-callable from a method call whose computed name evaluated undefined (PERRY_DISPATCH_DIAG shows object."undefined" falling through every tower), another shows a silent park. Diagnosis toolkit for whoever continues (all env-gated on the branch): PERRY_THROW_BT=1 (backtraces at not-callable/not-a-constructor throws + dispatch misses, names generated closures on a PERRY_DEBUG_SYMBOLS=1 build), [GASSIGN] global-write inventory, PERRY_NO_GLOBAL_ASSIGN=1 A/B gate.

Also: require("next/dist/server/config-schema") alone reproduces the boot-blocking layers in ~2 minutes — no bundle compile needed for that class of bug.

Known small gaps documented along the way (not blocking, worth their own issues): syntactic new Date()/Date.now() sites bypass installed global overrides (compile-time builtin fast path — Next's io() interception only fires through value paths); class X extends <closure-value> never invokes the parent ctor; Reflect.construct(Date, args, plainFnNewTarget) over-brands vs node.

[proggeramlug]

Two updates from working this on current main:

1. On tip-of-main the symptom changed from silent evaporation to a hard SIGBUS — /plain fed JSON.stringify(value, replacer, space) a corrupted value graph and the replacer walk crashed the server (Bus error: 10, 17-frame stack via stringify_array_with_replacer_pretty → js_json_stringify_full, called from the app-page-turbo renderer). PR #6055 hardens the three unguarded deref sites (ptr_derefable magnitude+alignment checks + a 10M array-length sanity cap) so the route is back to hanging per this issue instead of killing the server. (That PR also fixes an unrelated boot regression — #6044 TDZ × #6037 capture-refresh — that currently prevents the app from booting at all on main.)

2. The corrupted value graph itself is a strong lead for this issue. Captured poison data from the render's stringify input:

• a POINTER_TAG element pointing at a structure whose ArrayHeader.length reads as the low 32 bits of a neighboring heap pointer (2765094344 = 0xA4CFB4C8 vs neighbor 0x5bb_a4cf_b4c8) — i.e. an interior pointer into another allocation, mis-classified as GC_TYPE_ARRAY by the header-byte read;
• a raw untagged 64-bit value 0x0000002000000203 in an element slot (top 16 bits 0x0000 — not a NaN-boxed Perry value at all).

So something in the render path is producing NaN-boxed interior/garbage pointers — plausibly at the V8-fallback or flight-data boundary — and that same producer is a good candidate for why the render's output never materializes (the "evaporation"). Suggested next probe for whoever picks this up: instrument the producer side (where the stringify input graph is built) rather than the crash site; the poison values above are distinctive enough to trap on write.