Streamed <Loading> boundary silently dies when the trailing _fr resolution chunk is lost (host truncates stream) — plus _$HY.fe is never implemented #2958

Activity

1. brenelz commented on Jul 30, 2026

   

   brenelz

   on Jul 30, 2026

   ContributorAuthor

   More actions

   Correction — this is very likely not a Solid bug. Plain Solid SSR emits the _fr resolution correctly; my host stack was truncating the stream.

   I tested the same shape with plain renderToStream (no router, no Cloudflare), using the collect() + fragmentPatches() harness from packages/solid-web/test/server/loading-dynamic-fragments.spec.tsx — a boundary suspended on an async memo read, with a plain signal alongside it:

   const message = createMemo(async () => { await wait(50); return "hello" });
   const [count] = createSignal(0);
   <Loading fallback={<span>loading…</span>}>
     <p>{message()}</p>
     <p>{count()}</p>
   </Loading>

   Result: { "2_fr": true } — the fragment record settles, no bug. And the stream tail shows why:

   …$df definitions…</script><script>$R[5]($R[4],!0);</script>

   The _fr resolution is emitted as its own trailing chunk after the $df script. In my app that final chunk never arrives — the document ends at the $df(...) script, which is exactly why _$HY.r["…_fr"] sits pending forever with no .s, and why manually calling the resolver unsticks everything.

   So the sequence of events in the report stands, but the attribution does not: Solid writes the resolution, and the host integration (@tanstack/solid-router's renderRouterToStream / stream transform, on workerd) closes the response before Solid's stream has finished draining. I'll chase it there. Apologies for the noise.

   Two things that may still be worth a look on the Solid side, though neither is the cause:

   1. _$HY.fe is never implemented. $df() ends with _$HY.fe(e, t), generateHydrationScript installs fe(){}, and nothing in solid-js or @solidjs/web (src or dist) ever replaces the stub — verified live on a hydrated page (String(_$HY.fe) === "fe(){}"). If that hook is vestigial it could go; if it's meant to be wired, it's missing.
   2. The failure mode is silent and total. When that trailing chunk is lost for any reason, the boundary waits forever, renders fallback() into a detached tree, and every binding inside it — plain signals included — is dead after hydration, with no error. A dev-mode warning for "hydration finished with boundaries still pending on an unresolved _fr" would have turned a multi-hour hunt into a one-line diagnosis. (For what it's worth, I tried resuming off fe as a client-side safety net: it fixed my app in dev and prod, but regressed 5–10 of the 64 test/hydration specs depending on how I timed it — all [streamed] scenarios — because $df means "markup landed" while _fr means "data settled and flushed". So a naive fallback trigger isn't viable; a diagnostic seems like the better ask.)
2. brenelz

   changed the title [-]Streamed <Loading> boundary never resumes when its `_fr` resolution is dropped at stream close — every binding inside the boundary is dead after hydration[/-] [+]Streamed <Loading> boundary silently dies when the trailing `_fr` resolution chunk is lost (host truncates stream) — plus `_$HY.fe` is never implemented[/+] on Jul 30, 2026
3. brenelz commented on Jul 30, 2026

   

   brenelz

   on Jul 30, 2026

   ContributorAuthor

   More actions

   Refinement to my correction above: the stream is not truncated. The document completes, the $df swap arrives — only the _fr resolution is never emitted.

   I captured the raw response bytes for the failing page (production build, workerd via vite preview, real browser UA — note isbot sends curl down the buffered non-streaming path, which is why my first captures looked different):

   • </html> is present at offset 3883, and the stream keeps going after it: at 4160 comes <template id="…1112"> with the boundary's content, then the $df("…1112") call. So post-</html> chunks are delivered fine.
   • The only resolution calls in the whole document are the two data ones — )($R[7],"Hello World") and )($R[4],"Hello World").
   • There is no ($R[n],!0) call anywhere — the _fr form. In plain renderToStream output that call is the final chunk (<script>$R[5]($R[4],!0);</script>), which is what I compared against.

   Matching client state on that page: _$HY.r["…1113_fr"] has no .s, while _$HY.r["…1110"] (the data) is { s: 1, v: … }.

   So registerFragment's item.resolve() either never runs or runs after the serializer has stopped accepting writes in this environment, while the fragment reveal itself is emitted normally. The two-microtask deferral (resolve: err => queue(() => queue(...))) is still my main suspect for how the resolution loses the race against stream finalization — but the earlier framing of "the host closed the response early" was wrong, and I wanted that on the record.

   One more datum, in case it's a clue rather than a separate bug: in the production build the same page hydrates worse than in dev. In dev, a plain signal outside the boundary stays live (only bindings inside the boundary are dead); in the production build that outside binding is frozen too, suggesting the whole route subtree fails to claim there. Same code, same versions — dev vs. built worker.
4. brenelz

   closed this as completedon Jul 30, 2026
5. ryansolid

   added a commit that references this issue on Aug 4, 2026

   One reveal owner: the fragment ledger replaces claim sets and page scans

   ...

   40b05e1