Repository navigation
fix(signals): link a store reader to its derive's staged error (#4517) - #4519
Conversation
…js#4517) A derive marked with a staged error (`stageMark`, solidjs#4456) carries no STATUS_ERROR until the commit, so `pullFamily` took it for a settled derive and pulled it untracked. The pull threw the staged error before the reader read any leaf, so the reader subscribed to nothing in the family: when the derive's source re-asked and landed, neither the wake nor the settle reached it. An `<Errored>` mounted in the change that errored its content stayed on its fallback over a keyed `createProjection`, while the same read of the memo recovered. A reader now links to a derive carrying a staged error as it does to a pending or errored one, and re-runs at the landing. The render-effect early return in that branch is for a derive with a flight up only: a staged error is an answer the frame reader has to meet (D-41; the solidjs#3887 pin). Pins: packages/signals/tests/errored-born-staged-error-projection-4517.test.ts, packages/web/test/errored-born-staged-error-projection-4517.spec.tsx (the issue's repro). Size: +8 to +10 B minified on the store scenarios, every one under its brotli cap; the three over-cap warnings are +0 B over next.
The pullFamily comment block keeps its original lines, with one line on the staged-error pull in place of the three that narrated the issue. The web spec's header keeps only the jsxImportSource and vitest-environment pragmas, as the neighbouring specs do. The changeset states the behavior that changed in two sentences.
🦋 Changeset detectedLatest commit: 0d540e5 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 |
Merging this PR will degrade performance by 11.03%2 warnings
Warning Please fix the performance issues or acknowledge them on CodSpeed. Performance Changes
Tip Investigate this regression by commenting Comparing 
Footnotes
|
|
Thanks, @brenelz! Merged as 25b94f0. Two independent reviews agreed, and the PENDING-only early return checks out by D-3/D-41. Generated by Claude Code |
…4523, #4450, #4522) (#4528) Claude-Session: https://claude.ai/code/session_015hPxMkC3jg3Uivh65gvaf2 Co-authored-by: Claude <noreply@anthropic.com>
…rror (#4527) (#4533) * fix(signals): an effect's error boundary keeps no superseded staged error (#4527) Here is the case: an action re-asks a derived store and a memo, so its transition stays open. The store's re-ask is rejected (staged, D-41), and a second re-ask answers before the commit. An effect that created `createErrorBoundary(() => store, ...)` in its compute got the fallback at the commit and never ran again. - store: handleAsync's untracked shape probe of a returned proxy pulls the derive. When that pull throws a staged error, it now links the pass, as a tracked read does (#4519). The memo carries the error and stays reachable by the re-ask and the answer that supersede it. - boundaries: prune's "fresh boundary keeps its fallback until the reader commits" clause (#3540) applies to loading boundaries only. In an error boundary, a recovery that lands in the hold that staged the error joins that hold and reveals with its commit (D-39, D-41). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015hPxMkC3jg3Uivh65gvaf2 * fix(signals): trim the #4527 fix by 11 B minified on store rows, 4 B elsewhere - store: link the pass the staged error is thrown into whether the pull is tracked or not (a tracked read links anyway, and `link` dedupes). This drops the `tracking` test, and `c &&` replaces `c !== null`. - boundaries: an error boundary is born `_initialized` (the field is loading-only: no other error-boundary path reads it), so prune's #3540 clause stays as it was. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015hPxMkC3jg3Uivh65gvaf2 --------- Co-authored-by: Claude <noreply@anthropic.com>
Fixes #4517.
An
<Errored>mounted in the same change that errors its content stayed on its fallback after the next answer landed, when its content read a keyedcreateProjectionover a memo. Reading the memo directly recovered. This regressed in #4456.#4456's
stageMarkmarks a derive withCONFIG_STAGED_ERRORbut sets noSTATUS_ERRORuntil the commit.pullFamilylinked a reader to the derive only when the derive was pending or errored, so it pulled a staged-error derive untracked. The pull threw before any leaf was read, the reader subscribed to nothing in the family, and the landing never reached it.pullFamilynow links the reader to a derive that carries a staged error, the same way it links to a pending or errored derive, so the reader re-runs at the landing. The render-effect early return in that branch now requiresSTATUS_PENDING. For pending and errored derives this is the same condition. A frame reader of a held derive with a staged error now reads it and meets the error, whichderived-refetch-error-3887requires. The staged-error marking from #4456 is unchanged.Open: the frame-rule comment above the early return describes only pending and errored derives. It may need a ruling on whether staged errors belong to it.
How did you test this change?
cd packages/signals && npx vitest run tests/errored-born-staged-error-projection-4517.test.ts: the projection case fails onnextand passes with the fix.cd packages/web && npx vitest run test/errored-born-staged-error-projection-4517.spec.tsx: the issue's repro. The keyed case fails onnextwith"too short".server-functions-adapter-request.spec.tsx, which fails the same way onnext.