solidjs / solid / 40466331453

79%

main: 89%

push

github

fix(solid): hydration never asks again for an answer the server already sent (#4313)

* fix(solid,web): draw an Errored fallback for a Loading's async failure, and adopt it (#4287)

Outside a server component, a <Loading> whose async read failed during a
streamed render settled its fragment blank, and the hydrating client
rendered the failed boundary from scratch: it asked again and showed the
loading fallback.

Server: the failing <Loading> now asks the enclosing <Errored> for its
outcome outside server components too, passing its own id. The Errored
answers only when that Loading is all of its content (its resolved markup
is the Loading's placeholder): its fallback is drawn into the fragment, or
inlined pre-flush, and the error is serialized at the Errored id. Deeper
in the content it answers nothing, as before. A rejected fragment's
template is marked `e`, and `$dfr` records the nodes it swaps in for it.

Client: inside a hydrated Errored's no-claim content run, a <Loading>
runs its content with its data adopted instead of waiting on its
fragment, so the Errored holds the client's own error and tracks the
content's inputs (#4273). A boundary that claimed its fallback and then
renders a rejected fragment fresh clears the nodes the swap put in first,
so nothing of the server's outcome is left beside the client's render.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015hPxMkC3jg3Uivh65gvaf2

* fix(solid): serialize an Errored's error only when its fallback markup is sent

When a streamed <Loading> fails after the shell and asks the enclosing
<Errored> for its outcome, the fallback may hold an async hole that has
not resolved yet. renderOutcome then returns no markup (the fragment
settles as a plain rejection), but handleError had already serialized
the error at the Errored id. A client hydrating after the failure read
that record, claimed a fallback that was never sent, and went bl... (continued)

786 of 1076 branches covered (73.05%)

Branch coverage included in aggregate %.

20 of 20 new or added lines in 1 file covered. (100.0%)

1122 of 1352 relevant lines covered (82.99%)

28.09 hits per line