Repository navigation
Optimistic store property readers stay stale after reconciliation removes a property #3883
Description
Describe the bug
When an action adds an optimistic row and then retains it in a writable derived store with createFailed: true, a later source update reconciles the row without that property. Both the derived store and its optimistic view then contain { id: "A" }, but JSX reading cards[0]?.createFailed continues displaying Error.
The action has already settled before the source update. There are no pending actions when the stale UI remains.
Your Example Website or App
https://s.olid.uk/id/iKS1wleST9GNN_nKlC2RDg
Steps to Reproduce the Bug or Issue
- Open the reproduction and click Run once.
- The action optimistically inserts a row, then retains it with
createFailed: trueafter 100 ms. - After that action settles and another 200 ms passes, the source supplies
{ id: "A" }. - The page remains on Error, although reconciliation has removed
createFailedfrom both stores.
Expected behavior
The page should return to Confirmed when reconciliation removes createFailed, since reading the property now returns undefined.
Screenshots or Videos
No response
Platform
- OS: Linux (WSL)
- Browser: Chromium 153
- Solid: Zulu preview
bc51ada(solid-js, @solidjs/signals, @solidjs/web)
Additional context
Controls tested against the same build:
- Removing
createOptimisticStoreand rendering the derived store directly updates to Confirmed. - Supplying
{ id: "A", createFailed: false }instead also updates correctly. - The failure reproduces without
For, routing, or a database.
Direct snapshots after the source update show source, local, and cards all equal to [{ "id": "A" }], while the property-dependent JSX still displays Error.
Activity
GabbeV commentedon Oct 7, 2026
Narrowed this to the L2 rewrite in #3774:
41fdf9696(the merge's parent) and fails at1b9ceb679(the merge itself).bc51ada.The suspected defect is the absent-own-key branch of the store
gettrap. Present keys go throughserveDataKey, which reads through a chained backing unless the outer node carries an optimistic override. The absent-key branch instead returnsnodeValuedirectly, leaving the outer node's cachedtruevisible after the inner store removes the property.A clarification to the original evidence: JSON snapshots omit the key, but a direct property read can still return the stale
true. The core observer also re-runs and readstrue, so this is more specific than merely a missed notification.As an isolated control, inserting this immediately before that absent-key branch makes the core reproduction pass:
That is a diagnostic control, not a full-suite-validated patch.
size: raise signals + createStore and compiled hydrating caps for #3883
fix(signals): an optimistic view reads a property its inner store rem…
ryansolid commentedon Oct 8, 2026