2.0.0-beta-16 | optimistic update is not being rolledback when rendered from a derived store and a `<For>`

[mizulu]

Describe the bug

source for llm https://source.s.olid.uk/id/QQXR8CMkT_2BW2vmZm0arg

open the repro, wait until all pending async are resolved
it will finally render

however the {"id":100} is an optimistic update of the store
that should have rolled back after the store was refreshed and resolved.

-
For
{"id":1}
{"id":2}
{"id":3}
{"id":4}
{"id":100}

The console logs

itemStore Resolver Start
Sleep:3s
itemStore Resolver ended
Sleep:1s
Refreshing itemsStore
optimistic new item with id 100
itemStore Resolver Start
Sleep: 3s
itemStore Resolver ended

Your Example Website or App

https://s.olid.uk/id/QQXR8CMkT_2BW2vmZm0arg

Steps to Reproduce the Bug or Issue

.

Expected behavior

it is likely that the call

    setItemsStore((s) => {
      console.log("optimistic new item with id", new_ids)
      return [...s, { id: new_ids++ }]
    })

in addAndLoad()

should only show while the refreshing is going on
once it is resolved, that item should have been removed.

Screenshots or Videos

No response

Platform

• OS: [e.g. macOS, Windows, Linux]
• Browser: [e.g. Chrome, Safari, Firefox]
• Version: [e.g. 91.1]

Additional context

import { render } from '@solidjs/web';
import { createSignal, createOptimisticStore, Loading, isPending, refresh, For } from 'solid-js';

export default function App() {
  async function sleep(ms = 1000) { 
    console.log("Sleep:", ms/1000 + "s")
    await new Promise(r => setTimeout(r, ms)) 

    }
  let base = [{ id: 1 }, { id: 2 }, { id: 3 }]
  let new_ids = 100;
  const [itemsStore, setItemsStore] = createOptimisticStore(async () => {
    console.log("itemStore Resolver Start")
    await sleep(3000)
   
    base = [...base, { id: base.length + 1 }]
    
    console.log("itemStore Resolver ended")
    return base
  }, [])

  const [mainStore, setMainStore] = createOptimisticStore(() => {
    return { theItems: itemsStore }
  }, {});




  async function addAndLoad() {

    await sleep(1000);
    console.log("Refreshing itemsStore")
    refresh(itemsStore)


 
    setItemsStore((s) => {
      console.log("optimistic new item with id", new_ids)
      return [...s, { id: new_ids++ }]
    })


  }
  setTimeout(async () => {

    addAndLoad()
  }, 5000)

  const [count, setCount] = createSignal(0);
  return (
    <div class="p-2">
      <Loading fallback={"Loading.."}>

        <div>

          {isPending(() => {
            return [...itemsStore]
          }) ? "ItemsStore Pending?" : "-"}

          <h1>For</h1>
          <For each={mainStore.theItems}>
            {v => {
              return <div>{JSON.stringify(v)}</div>
            }}
          </For>
        </div>

      </Loading>
      <button class="bg-blue-500 hover:bg-blue-700 text-white font-bold py-2 px-4 rounded" onClick={() => (addAndLoad(), setCount(count() + 1))}>
       Click to add a new item: {count()}
      </button>
    </div>
  );
}


if (typeof document !== 'undefined') {
  render(() => <App />, document.getElementById('root')!);
}

[mizulu]

narrowing this down a bit
this is related to the <For>

in this version I have JSON.stringify the store state, and we can see the rollback
but the For is hanging on to that item.

playground : https://s.olid.uk/id/Cm0i4UkzQCe_YDnQOdcaBA
source: https://source.s.olid.uk/id/Cm0i4UkzQCe_YDnQOdcaBA

[brenelz]

This is the details I've been able to find:

Confirmed. The rollback is working: after refresh, mainStore.theItems contains id: 4, not id: 100. The stale value is specific to .

This is a store-in-store structural tracking issue. tracks the outer derived store’s array structure, while reconciliation notifies the nested itemsStore. Because id: 100 is replaced by id: 4 without changing the array length, is not invalidated and keeps its cached row.

Rendering itemsStore directly avoids the issue. The likely fix is to forward structural $TRACK reads through nested store proxies, with a regression test covering same-length reconciliation.

[ryansolid]

Fixed in 3e18b8d (next), will be in the next beta release.

@brenelz's diagnosis was exactly right — this was a store-in-store structural tracking gap, not a rollback failure. The rollback itself worked (the store data was correct after the refresh landed), but <For> subscribes to the array's structure via a $TRACK self-node, and when a derived store returns another store it wraps it in its own proxy view with its own node record. Structural notifications from reconcile land on the inner store's self-node, so <For> reading through the outer derived store never re-ran — it kept its cached row for id: 100 even though a fresh read showed id: 5. Reading itemsStore directly worked because that subscribes to the inner store's self-node directly.

trackSelf now chains the wrapper view's $TRACK read through to the wrapped source (except while an override layer holds on the view — the reveal notification re-establishes the chain). This also fixes Object.keys enumeration and snapshot()/deep() through derived stores, which had the same blind spot. Regression tests cover the <For>/mapArray path from your repro, enumeration, and the mid-transition hold semantics.

Thanks for the repro and especially for narrowing it to <For> — that isolation is what pointed at structural tracking rather than the optimistic overlay.

[mizulu]

confirmed fixed in 3e18b8d

https://s.olid.uk/id/G0sAFVsHRnWqQ1KyCvL85g