Skip to content

fix(signals): derived store sync landing wakes parked readers - #3732

Open
brenelz wants to merge 2 commits into
solidjs:nextfrom
brenelz:claude/issue-3726
Open

brenelz wants to merge 2 commits into
solidjs:nextfrom
brenelz:claude/issue-3726

Conversation

@brenelz

@brenelz brenelz commented Oct 1, 2026

Copy link
Copy Markdown
Contributor

Fixes #3726

What was broken

A derived createStore whose first run returned a pending promise, and whose rerun after a source write returned a value synchronously, left some readers pending forever. A reader whose store node the landing did not change ("length" in store, Object.keys, an unchanged length) rendered blank inside ``, while a sibling read of the source updated.

Root cause

The projection computed kept STATUS_UNINITIALIZED until the flush commit, because recompute clears it only on a creation pass. The settle walk that releases readers parked on a superseded flight skips uninitialized nodes, and unchanged-node readers get no value notification to fall back on.

Change

After the synchronous commit, runProjectionComputedNext clears STATUS_UNINITIALIZED when the node's own flight was pending and no transaction holds the landing, the same way the async landing path does after its setter commit. A landing held by a transaction (a live action, a blocked transition, or another pending source) keeps the flag, so the seed stays invisible until that transaction commits.

Verification

  • cd packages/signals && npx vitest run tests/store/derived-presence-async-3726.test.ts: 3 passed. Two of the cases fail on next without the fix.
  • packages/signals: 4794 passed. packages/solid: 817 passed. packages/web: default, hydrate and server suites pass, except one server spec that also fails on next.

Open

  • The fix could instead live in core recompute, which would cover every computed type.
  • When a transaction holds the landing, readers parked on the superseded flight still do not wake after the commit. This happens on next too.

…s#3726)

A derived store whose first run returned a pending promise and whose rerun
landed synchronously kept STATUS_UNINITIALIZED on the projection computed
until the flush commit, because recompute only clears the flag on a
creation pass. The recompute-side settle walk (solidjs#3181) requires the node to
be initialized, so it skipped the projection, and readers subscribed to a
store node the landing left unchanged (`"length" in store` on an array
seed, `Object.keys`, an unchanged `length`) had no value notification to
fall back on. They stayed pending, blank inside a loading boundary, while
a sibling read of the source updated.

The projection's sync commit through the setter now retires the flag the
way asyncWrite does after its setter landing, so the walk releases those
readers in the same flush. The retirement is gated on the previous run
having been pending, which leaves a born-held creation pass unchanged.
The projection computed retires STATUS_UNINITIALIZED after a synchronous
landing only when the pass is mainline or its transaction is parked by
nothing but the node's own flight, so a landing staged by a live action
or beside another pending source keeps the seed invisible until that
transaction commits. The gate is keyed on the node's own pending-source
entry instead of any STATUS_PENDING, so a first run parked on an
upstream async source no longer trips it. The tests assert in the flush
that lands the sync value, register a length reader, and pin the
transaction-held case.
@changeset-bot

changeset-bot Bot commented Oct 1, 2026

Copy link
Copy Markdown

🦋 Changeset detected

Latest commit: 37ac480

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 12 packages
Name Type
@solidjs/signals Patch
test-integration Patch
@solidjs/web Patch
@solidjs/babel-plugin Patch
@solidjs/compiler Patch
@solidjs/diagnostics Patch
@solidjs/element Patch
@solidjs/h Patch
@solidjs/html Patch
solid-js Patch
@solidjs/universal Patch
todos-server-example Patch

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

@codspeed

codspeed Bot commented Oct 1, 2026

Copy link
Copy Markdown

Merging this PR will not alter performance

✅ 185 untouched benchmarks
⏩ 3 skipped benchmarks1


Comparing brenelz:claude/issue-3726 (37ac480) with next (309b087)

Open in CodSpeed

Footnotes

  1. 3 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant