2.0.0-rc.5 optimistic store resets when new data arrive

[GabbeV]

Describe the bug

Optimistic store that get new data while it already has an override resets it optimistic override revealing that data immediately.

Your Example Website or App

https://stackblitz.com/edit/solidjs-templates-5ffe6n2m?file=src%2FApp.tsx

Steps to Reproduce the Bug or Issue

1. Open repro
2. Click button
3. Observe how it goes [1] [1,2] [1] [1,2] instead of just [1] [1,2].

Expected behavior

The override should remain until the transition settles.

Screenshots or Videos

No response

Platform

• OS: Windows
• Browser: Firefox

Additional context

No response

[GabbeV]

zulu pointed out that maybe I shouldn't be yielding in the projection. I thought that was required like in actions but maybe not, however even if that yield represent a new value it shouldn't be breaking like this. But maybe we need some warnings or errors here to guide usage?

[ryansolid]

Fixed in 42b3fbf (will ship in 2.0.0-rc.5). Thanks for the sharp report — this exposed a real inconsistency in how landings consume optimism, and the fix is a clarification of the intended rule rather than a special case.

The ruling: landing consumption is now equality-scoped. A landing consumes a target's structural optimism only when it contradicts the base the optimistic edit was applied on — for arrays that's any index/length change, for objects a membership change. Your interim poll lands data identical to the base the push was applied against, so it carries no new information about that list: the override now holds with its owning transaction instead of flash-reverting. Your repro renders [1, 2] steadily through the interim landing, then stays [1, 2] when the confirming refetch lands (the consume is value-equal, so it's seamless).

Two boundaries worth stating explicitly:

• A landing that does change the list (someone else's row arrives mid-flight) still consumes the structural override — authoritative truth wins over positional optimism, because unkeyed edits are anchored to the exact arrangement they were computed on and can't be soundly rebased across a different one.
• If the action completes without the server confirming, the held override reverts at transaction settle — so the flash you saw can still happen, but only at the honest moment (your edit was actually rejected), never from poll timing.

Rebasing keyed structural optimism across changed landings (so a concurrent foreign row wouldn't consume your pending add either) is a coherent stronger contract we've recorded as a post-RC design item — it needs a satisfaction rule for when landed truth carries your key.

[GabbeV]

@ryansolid This does not seem to have fixed it. If I use the delay promise at the end of the action as the repro was originally then it behaves exactly like before. Changing to until doesn't fix it. If I change to a real until check at the end instead the first click behave like it did before and subsequent clicks don't get any optimistic state at all.

[GabbeV]

Scratch the difference in subsequent clicks. I forgot that I was reusing ids. Changing that made each click behave like the first.

[ryansolid]

Reopening — you're right, and this time I pulled your actual StackBlitz source rather than reconstructing it. Confirmed on current next: [] [0] [0,1] [0] [0,1] — the second action's pending item flashes out when the first action's confirmation lands, with either the until or the delay-promise ending.

What the earlier fix covered is real but narrower than your case: a landing carrying data equal to the base now holds overrides (an interim poll no longer flash-reverts), and a single action's own confirmation consumes value-equal (seamless — verified as a control). Your repro is the case beyond it: two overlapping transactions. The landing from add(0)'s confirmation legitimately changes the array's arrangement, which under the current rule contradicts and consumes every positional override on that target — including add(1)'s still-pending push, which is owned by a transaction the landing says nothing about.

That per-target (rather than per-transaction) consumption is the precise gap, and it's the "satisfaction" design we had recorded: a landing should release the overrides it accounts for, not everything standing on the arrangement. Working out the ruling now — an append-shaped override arguably makes no claim about the existing arrangement at all (its intent is "at the end", which survives a changed tail), which may give this a clean rule rather than a keyed-rebase prerequisite. Will follow up here once it's settled.

On the bare yield; — it lands nothing (treated as no-data), so it isn't implicated in the flash; the landing channel in your shape is the store.push(item) draft write. Whether an undefined yield deserves a dev warning is a separate, smaller question we'll take with this.

[GabbeV]

Don't we need the updates to entangle here given they all touch the same array?

if the first update fails, making the authoritative state [] then .push(2) would have to be replayed to let the second updates optimistic overlay remain. React does things like this but I don't think Solid does and the alternative would be to force them to entangle so reverting the first updates optimistic waits for the second update to complete.

[ryansolid]

Fixed in 5b61935 (will ship in the next rc). The model changed underneath, so a short explanation of what your repro now does and why.

What was wrong. Optimistic edits were stored as node-level patches against the base arrangement they were applied on. When any landing changed that arrangement — including your own action's confirmation arriving while a second action was still pending — the patches were positionally meaningless and got consumed, which is the flash you saw. The equality gate from the first round only fixed the interim landings that carried no change; your overlapping-actions case landed real changes and still flashed.

What it does now. The store retains the setter call itself per transaction. When a landing from the live stream (a continuation — your generator's store.push, later yields) contradicts the base, the store wipes the materialized overrides and re-executes every still-open transaction's setters against the landed truth. Your exact repro now renders [] → [0] → [0,1] with no flash and no duplicates in both endings (until and the delay variant): the confirmation's echo of your own row is recognized by key and deduped, and the second action's pending push re-derives its position on the new base.

Two contract notes worth knowing:

1. Setters are reducers. They re-run whenever authoritative truth changes beneath them, so they must be pure draft mutations that tolerate any plausible base (your existing spelling already is, since your rows carry client-generated ids — keyed rows get echo-dedupe for free). For unkeyed data, a blind push can duplicate during an echo window; the guard is the usual if (!draft.some(...)) draft.push(...).

2. Replacement landings still replace. A re-invocation of the derive — navigation, refresh, a polling refetch — is a complete restatement of the store's truth: it consumes pending optimism rather than rebasing it (that's 2.0.0-beta.14: Optimistic updates tearing fresh data #2719's contract, unchanged). The distinction is the API shape: a refetch says "here is the whole truth again"; a continuation stream like yours says "incremental updates to one living collection" and rebases. If you want live-feed semantics under concurrent optimism, the continuation spelling you're already using is the right tool.

Thanks for pushing on this one — the repro was exactly what forced the model to get honest.

[GabbeV]

I think this is still wrong. The replay correctly avoids the entanglement between the separate add updates. But optimistic is still disappearing before the update, being held back by the action, is done. I show this in the repro now using both using and then a delay promise at the end of the action.

The mechanism needed to handle this properly I think is that until() makes the update it is called in entangle with the update that makes it truthy. This allows the confirmation to be held back by the action that is still running.

[GabbeV]

@ryansolid I can open a separate issue if you want but think maybe the context is useful