Repository navigation
fix(solid): hydration never asks again for an answer the server already sent - #4313
Merged
Merged
Conversation
…e, 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
…p 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 blank with a hydration key miss. The outcome path now defers the record and writes it only once the fallback resolved to finished markup. Without it the client renders the failure itself, as on `next`. Server-only; no client bytes. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_018LY7F9czoRqdMEvk2QwPr1
…resolves (#4306) An <Errored> whose fallback reads async data, around a <Loading> that fails after the shell inside an outer <Loading> still pending, lost its region: the outcome render met the fallback's pending hole, answered no markup, and the parked fragment spliced a blank into the outer one while its `_fr` resolved. The client claimed against the blank and showed nothing there, with hydration warnings. renderOutcome now answers a still-resolving fallback with a function that waits out its holes and returns the finished markup, serializing the error only then. The <Loading> calls it only while its fragment is parked in an enclosing pending one (the registry's new `parked()` query on the settle function), where nothing of the failure shows yet: the outer fragment carries the fallback, or, if the outer settles first, the inner fragment streams it when it lands. A failure in a region already shown settles at once, as before. Server-only; no client bytes. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015hPxMkC3jg3Uivh65gvaf2
…c holes (#4306) Per RULES-DERIVED D-18 (a swap to a fallback waits for the fallback to be ready), the wait for an Errored fallback's async holes no longer depends on the fragment being parked. A <Loading> that fails after the shell under an <Errored> whose fallback is still resolving keeps its placeholder until the finished fallback is ready, then streams it with the error record, in the parked case (carried by the outer fragment while that is pending) and the unparked one alike. The registry's `parked()` query is dropped. #4303's async-fallback scenario now expects the server's finished fallback and its record: a client hydrating after the failure arrived claims it and asks nothing again. Server-only; no client bytes. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015hPxMkC3jg3Uivh65gvaf2
…-x1ore2-4306 # Conflicts: # packages/solid/src/server/hydration.ts # packages/solid/src/server/signals.ts # packages/web/test/harness/__artifacts__/errored-loading-postflush-rejection-async-fallback-4287.json # packages/web/test/harness/scenarios.tsx # packages/web/test/hydration/errored-async-outcome-4287.spec.tsx
…ad of asking again (#4287, #4306) A client hydrating mid-stream asked again for an async memo whose server read failed, and flashed back to the inner <Loading> fallback after the failure showed: Errored > Loading > read, with the read failing after the shell, unparked (the fragment rejects and the client renders the failure fresh over the swapped-in Errored fallback) or parked in a pending outer Loading (the outer resume runs the hydrated Errored's content, NO_CLAIM). Both content runs read the shell memo a cycle after its error landed, and a later tracked read retries an errored async node (PJ-R35). The retry re-enters the hydration latch, which since f3da41e has taken every re-entry for a dependency change ("re-entry is always invalidation- driven"), and since b68a907 computes such a rerun at once for a shell node outside the claim in progress: one real ask, the Loading fallback for its duration. Before f3da41e the latch re-served the serialized answer on every re-entry while hydrating, so the retry asked nothing. Inside a hydrated failure's content run (NO_CLAIM) a latched rerun now re-serves the server's answer, its error included, and arms nothing. A rejected fragment's fresh render runs as such a content run when the swap brought the outcome the server drew for the failure (the reveal record lists its nodes); to make that list the outcome alone, a rejected fragment with no outcome streams an empty template instead of a lone space. Uncontained failures (no outcome) keep rendering fresh as before. Tests: the #4287/#4306 hydration specs stream piece by piece with a clock tick between pieces (the plain-fallback case only passed because no flush ran between the error landing and the fresh read), assert 0 asks in both modes and no flash back to a loading fallback, and cover the parked plain-fallback scenario, which now has an ask counter and an update pass (the Errored tracks the memo, #4273). Size: 0 B on every CSR scenario (compiled floor 9,966 B); +65-71 B minified on the hydrating scenarios. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015hPxMkC3jg3Uivh65gvaf2
…rs instead of asking again Hydrated mid-stream, an async shell memo `b` reading another, `a`, both read only inside a streamed <Loading>, asked again when `a`'s server answer arrived: the landing re-ran `b`, and the hydration latch took the rerun for a client write (f3da41e's "re-entry is always invalidation- driven"; b68a907 computes it at once for a shell node). The server's `b` was computed from that same `a`; nothing on the client diverged. The latch now has one rule: a latched rerun inside hydration's own pass over served answers (NO_CLAIM) re-serves its own answer and arms nothing. That pass is a hydrated failure's content run (the Errored's, or a rejected fragment's fresh render over the outcome the server drew, from the previous commit) and, new here, a served answer's arrival: readHydratedValue hands the runtime a thenable whose landing runs, with the flush that carries it, under NO_CLAIM. The NO_CLAIM check moves to the head of the latch rule, so in-claim and held reruns there re-serve without arming a takeover too. Client writes still compute (the write-before-resume, nav-before-resume and hydration-latch pins), and a retry outside that pass still follows the client rule. Tests: a parity scenario and spec for the b-reads-a shape (0 asks loaded and streamed piece by piece with clock ticks, one real ask after a client write to their input); both fail before this commit. Size: 0 B on every CSR scenario (compiled floor 9,966 B); +19-27 B minified on the hydrating scenarios over the previous commit. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015hPxMkC3jg3Uivh65gvaf2
A served answer's arrival is hydration's own pass (NO_CLAIM): a latched node re-running there re-serves its server answer. A client write carried by that same flush must still make the node compute. - Client writes already made (pending, unflushed) flush first, outside the pass (`servedPass`). The async runtime's landing flushes synchronously, and that flush would otherwise carry them. - The pass covers only the flush round its served write lands in (`_servedAt = clock`). An effect's write runs in a later round of the same flush, and a latched node re-run there computes. The latch tests `clock > _servedAt`. `@solidjs/signals` exports its flush-round counter (`clock`), an internal live binding, at 0 B. Landings cannot be coalesced into one pass per microtask batch without changing signals. `asyncWrite` already flushes synchronously on every landing (`schedule(); flush()`) at the #4308 head, so a served pass adds no flush per landing. Its trailing `flush()` is a no-op after a value landing. Tests: in served-source-landing, a write before the flush and an effect's write in the landing's flush both give the written value with 1 ask. Both fail on 2b2990a. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015hPxMkC3jg3Uivh65gvaf2
🦋 Changeset detectedLatest commit: 6c35714 The changes in this PR will be included in the next version bump. This PR includes changesets to release 15 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
Size (brotli, eager entry chunk)
|
Member
Author
|
The size gate is red for this PR's own bytes (about +130 B minified on the hydrating paths). Four scenarios are now over their brotli cap and more than 20 B over their recorded size:
Part of the headroom on the live pages went to #4304, which landed on Generated by Claude Code |
…-x1ore2-hydrate-reask
Coverage Report for CI Build 40463844669Coverage decreased (-0.006%) to 78.583%Details
Uncovered ChangesNo uncovered changes found. Coverage RegressionsNo coverage regressions found. Coverage Stats
💛 - Coveralls |
This changes no behaviour. Client bytes over next go from about +130 B to +58 B minified. - A hydrated `<Errored>`'s content run and a served pass are one window kind: `_claimOwner = ~clock`, a window over no owner for the flush round it opened in. `~` keeps it truthy when clock is 0. - That replaces both `NO_CLAIM` and `_servedAt`. The latch checks one thing, `_claimOwner !== ~clock`, and a later round of an arrival's flush (an effect's write) still computes. `isClaiming` reads a number as no owner, so nothing claims, as before. - `servedPass` is curried (`servedPass(f)(x)`), so the arrival thenable is `initP.then(servedPass(a), servedPass(b))`. - A resume clears the hydration flag once, before either branch. The fresh branch's own flush was redundant with the resume's trailing one. The outcome check reads `?.[0]` instead of `?.length`. The pre-flush stays on both paths. Removing it makes the write-before-landing test fail, and comparing only `_claimOwner` without the round makes the effect-write test fail. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015hPxMkC3jg3Uivh65gvaf2
Merging this PR will improve performance by 15.15%2 warnings
Performance Changes
Tip Curious why performance improved? Comment Comparing 
Footnotes
|
ryansolid
marked this pull request as ready for review
October 27, 2026 03:42
…-x1ore2-hydrate-reask # Conflicts: # packages/web/test/harness/scenarios.tsx # packages/web/test/hydration/errored-async-outcome-4287.spec.tsx # packages/web/test/hydration/errored-parked-async-outcome-4306.spec.tsx
A recover only runs while hydrating, so the guarded globalThis read is dead weight: -12 B minified on every hydrating and page scenario. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_018LY7F9czoRqdMEvk2QwPr1
Keeps both sides of the harness scenarios and the 4306 spec imports. #4318's new artifacts and its rejected-fragment expectations take this branch's empty outcome template (`e></template>`, no lone space). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_018LY7F9czoRqdMEvk2QwPr1
ryansolid
pushed a commit
that referenced
this pull request
Oct 27, 2026
…eeds markSnapshotScope's served branch only sees hydrated signal-likes, never the internal boundary signals that carry CONFIG_NO_SNAPSHOT; a settled answer already took its creation snapshot, so the landing hook needs no `!initP.s`. -16 B minified on the hydrating and page scenarios; keeps the store app within the size gate's allowance now that #4313 is on next. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_018LY7F9czoRqdMEvk2QwPr1
ryansolid
added a commit
that referenced
this pull request
Oct 27, 2026
…client's value (#4314) * fix(solid,signals): a boundary claimed after a shell write shows the client's value A hydrated memo adopted while its server answer was still streaming had no snapshot (the creation arm skips pending nodes). Since b68a907 a shell node outside every pending boundary computes on a client write; a streamed <Loading> that reads it and resumes afterwards then claimed its server markup while reading the client's value, and since the claim pass never mutates the DOM, the binding kept the server's text for good (GH2). With the client's recompute still in flight at the resume, the claim read the node pending and the never-revealed boundary committed its fallback over the settled server content, detaching it and losing a queued click (GH4). - solid: a value node's server answer still streaming at adoption becomes its snapshot when it lands (readSerializedOrCompute), whether the node committed it or a client write had already taken the compute over. The claim reads what its markup shows and replays the client's value at the scope's release, as for a written signal. - signals: markSnapshotScope(node, served) records that snapshot (no new export); a reader in a snapshot scope is served the snapshot ahead of the node's pending state (errored nodes still throw), so a revealed claim holds while the client's flight is open. takeSnapshot folds the three copies of the snapshot write. Tests: hydration/claim-stale-text (signal / sync / async shell sources; a chained pair of pending shell memos with the write before, between and in the flush of their answers, settled or in flight at the claim — no fallback after the fragment, no diagnostics); the generic consistency pins GH2 and GH4 flip from test.fails to passing; signals snapshot unit tests for the served snapshot. Size: 0 B minified on every CSR scenario (compiled floor 9.97 KB brotli); +61..69 B minified on the hydrating scenarios. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015hPxMkC3jg3Uivh65gvaf2 * perf(solid,signals): drop two checks the served-snapshot path never needs markSnapshotScope's served branch only sees hydrated signal-likes, never the internal boundary signals that carry CONFIG_NO_SNAPSHOT; a settled answer already took its creation snapshot, so the landing hook needs no `!initP.s`. -16 B minified on the hydrating and page scenarios; keeps the store app within the size gate's allowance now that #4313 is on next. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_018LY7F9czoRqdMEvk2QwPr1 --------- Co-authored-by: Claude <noreply@anthropic.com>
ryansolid
pushed a commit
that referenced
this pull request
Oct 30, 2026
…arried A first ask of a memo the server never streamed is not a refetch (#4313, #4414): the emitted app reports each memo's hydration id before creating it, and the hydration campaign counts an ask only when the shell or a chunk carries that id's answer. Re-run on next: the one remaining hydration finding (m2 after an errored root) goes away; 251 of 561 memos are served and still checked. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0117BoWKJDzwaZPgaGWE181b
ryansolid
added a commit
that referenced
this pull request
Oct 30, 2026
…arried (#4446) * test(web): async app generator — generated Loading/Errored/Show trees over async memos, with safety and liveness oracles An opt-in campaign (ASYNC_GEN=1, pnpm async-gen) that generates small apps (signals, sync and async memos with manual flights, latest()/isPending() reads, Loading / Errored / Show / leaves with grouped or split attribute effects) and scripts (writes, actions, settling flights in any order, flush / microtask / task). Oracles: nothing throws or logs, no unhandled rejection, no hole shows undefined/NaN, and once every flight has settled the screen equals a fresh synchronous render of the final inputs. Survey, shrink and minimize modes; the minimizer reduces the app as well as the script. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0117BoWKJDzwaZPgaGWE181b * test(web): async-gen equivalence pairs (grouping, identity memo, inert Errored, store twin, flush mode, owned memos) ASYNC_GEN_PAIRS=E1,E2,E2e,E3,E6,E7 runs each scenario a second time rewritten without changing its meaning and compares the screens at every settle point (after the first render, each task step and the end); differences are grouped by what each side shows. Scenarios also choose whether memos are created at module level or inside the root component. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0117BoWKJDzwaZPgaGWE181b * test(web): async-gen regression gate against a recorded baseline 1,500 generated scenarios (seed 3289, ~15 s) run with the web suite; each case's safety and liveness laws are compared to baseline.json. A case that newly breaks a law fails the suite (a change broke a neighbouring shape); a recorded failure that no longer reproduces is reported, and ASYNC_GEN_UPDATE=1 records it. The baseline holds today's 20 failing cases (#4362-#4367 shapes). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0117BoWKJDzwaZPgaGWE181b * test(web): async-gen hydration phase Each generated scenario is emitted as a TSX module, rendered through renderToStream (server half), then hydrated chunk by chunk (client half). Oracles: no refetch of a read memo before the first write, no console.error or hydration warning, hydrated screen equals a fresh CSR render, then the scenario's steps and final liveness. Opt-in via ASYNC_GEN_HY=1 (pnpm async-gen:hydrate); minimize-hydration.mts reduces a failing case through both halves. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0117BoWKJDzwaZPgaGWE181b * test(web): async-gen differential mode; fix test-types ASYNC_GEN_RECORD on a reference build writes every case's screens, final screen and broken laws; ASYNC_GEN_DIFF on a candidate build replays the same seed and fails on any difference. Both the client campaign and the hydration campaign take it: the gate for the reader-seat carve. Same-build record/diff is clean (client 500 cases, hydration 300). minimize-hydration.mts loads minimize.ts through a computed specifier so tsc (no allowImportingTsExtensions) accepts it; runCase's return type names screens/final. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0117BoWKJDzwaZPgaGWE181b * test(web): async-gen pairs E8 (birth seat) and E9 (latest in a derive) E8 re-creates the tree's readers in the flush that applies each write and compares screens where nothing is in flight; E9 reads each latest(x) the tree makes through a memo of it. Both from the carve audit's seat pairs. First run (1,000 cases): #4377, #4378. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0117BoWKJDzwaZPgaGWE181b * test(web): async-gen refetch oracle counts only answers the payload carried A first ask of a memo the server never streamed is not a refetch (#4313, #4414): the emitted app reports each memo's hydration id before creating it, and the hydration campaign counts an ask only when the shell or a chunk carries that id's answer. Re-run on next: the one remaining hydration finding (m2 after an errored root) goes away; 251 of 561 memos are served and still checked. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0117BoWKJDzwaZPgaGWE181b * test(web): quote the no-refetch rule in the hydration oracle Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0117BoWKJDzwaZPgaGWE181b --------- Co-authored-by: Claude <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Stacked on #4308. Review only the commits after 584e145 (d9a7a49, 2b2990a, 7ce4011, fae0320; b8014e1 is a merge of
next). Once #4308 merges, the diff shrinks to those.Before: a client that hydrates mid-stream asks again for async reads the server already answered.
<Errored>(the [2.0 / next] SSR: a boundary that fails through an async read renders no error fallback outside server-component scope, and hydration asks again #4287/Errored fallback with an async hole is dropped inside a pending outer Loading (SSR streaming) #4306 shapes) is re-asked once. With<Loading>inside, the boundary briefly flashes back to its loading fallback after the failure has shown.After: every one of these shapes asks 0 times, loaded or streamed, with no flash. A real client write during hydration still computes and asks exactly once.
This regressed in f3da41e (2026-08-26, "hydration-latched nodes lose mid-stream dependency changes"). It treated every re-run of a node holding its server value as a dependency change. Two kinds of re-run aren't:
b68a907 (2026-09-29) then made such a re-run compute immediately, which is where the flash comes from.
How:
readSerializedOrCompute's latch re-serves its own serialized answer, errors included, and arms nothing when it re-runs inside one of hydration's own passes over the server's answers:<Errored>'s content run;_claimOwner = ~clock: no claim owner, valid only for the flush round the pass opened in. This replacesNO_CLAIM. A write an effect makes during the landing's flush lands in a later round and computes.servedPassflushes earlier client writes before a landing's pass starts, so they're never swallowed. Signals' existingclockis exported@internal(0 B).served-source-landingscenario and spec cover B-reads-A plus two write races: a write before the landing's flush, and an effect write during it.hydration-latch,write-before-resume,nav-before-resume,client-hydration).Unchanged on purpose: a failure no
<Errored>caught on the server is still rendered fresh by the client and asked again (#4242's recovery tests). That call is with the maintainer.Size against
next: +56 to +63 B minified on the hydrating and page scenarios. CSR, the signals floors, the server scenarios and the compiled floor (9,966 B brotli) are unchanged. The gate passes with no cap raised.🤖 Generated with Claude Code
https://claude.ai/code/session_015hPxMkC3jg3Uivh65gvaf2