Confirming one overlapping optimistic-store action holds an independent signal update

[GabbeV]

Describe the bug

Confirming one optimistic-store action while another is still pending can hold a later, independent signal update. A memo combines the signal with a card ID that neither action changes:

const condition = createMemo(() => drag() === cards[0].id);

After the first action confirms and updates the authoritative store, a later task calls setDrag("0"). The second action remains open. latest(drag) becomes "0", but drag() stays unset and isPending(drag) is true.

Your Example Website or App

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

Steps to Reproduce the Bug or Issue

1. Open the playground, click Build, then Run reproduction.
2. Observe drag: unset, latest: 0, and pending: true.

The button starts two optimistic moves, confirms the first while the second is pending, awaits a timer to separate the drag write into a later task, then sets drag. No explicit flush() is used.

Expected behavior

The independent signal update should publish: drag: 0 and pending: false, while the second move remains pending.

Platform

• OS: Linux
• Browser: Chromium 153.0.8010.12
• Solid: mizulu/solid2@6958367 preview build (compiler and runtime)

Additional context

The earlier repros in #3688 and #3698 pass with this build. Controls also publish the drag update when only one move is open, when both moves stay open, or when the first settles before the second starts. The distinguishing sequence is confirming the first move after the second has started but before it settles.

[GabbeV]

Another reproduction of the independent drag hold, this time through nested <Show> in a preview: https://s.olid.uk/id/XnpLL12aTu2LWhkr9Hf6eA

Click Build, then Run. The button starts six overlapping optimistic moves, setting and clearing a separate drag signal between them. On mizulu/solid2@6958367, the sixth write shows drag=unset latest=1 pending=true. I verified this in both development and production builds.

The preview reads the optimistic store under <Show when={drag()}>:

<Show when={drag()}>
  {active => <Show when={cards.find(card => card.id === active())}>
    {card => <span>Preview {card().id}</span>}
  </Show>}
</Show>

Replacing the inner <Show> with <span>Preview {active()}</span> makes all six drag writes commit (pending=false). The repro has no router, database, pointer handling, or app components.

[GabbeV]

A related case still reproduces on the 3505f60 preview (development and production). The original two-move repro passes with this fix; I don't mean this as evidence that the fix is insufficient for that case.

Here, only one action writes the authoritative rows before yielding. A separate click then sets drag. The preview reads the derived/optimistic card store. While the action is open, latest(drag) is "card", but drag() remains unset and isPending(drag) is true. Removing the preview's cards.find(...) read makes the drag publish immediately, with the row update still pending. The card's id is unchanged (version changes); reading just cards[0].id in the preview also holds.

import { Show, action, createMemo, createOptimisticStore, createSignal, createStore, isPending, latest } from "solid-js";
import { render } from "@solidjs/web";

const delay = (ms: number) => new Promise<void>(resolve => setTimeout(resolve, ms));

function App() {
  const [rows, setRows] = createSignal([{ id: "card", version: 0 }]);
  const serverCards = createMemo(() => rows());
  const [localCards] = createStore(() => serverCards(), []);
  const [cards] = createOptimisticStore(localCards);
  const [drag, setDrag] = createSignal<string>();
  const move = action(function* () {
    setRows([{ id: "card", version: 1 }]);
    yield delay(3000);
  });

  return <>
    <button onClick={() => void move()}>Make data pending</button>
    <button onClick={() => setDrag("card")}>Start drag</button>
    <Show when={drag()}>
      {id => <Show when={cards.find(card => card.id === id())}>
        {card => <p>Dragging {card().id}</p>}
      </Show>}
    </Show>
    <pre>{JSON.stringify({ drag: drag(), latest: latest(drag), pending: isPending(drag), serverPending: isPending(serverCards) })}</pre>
  </>;
}

render(() => <App />, document.getElementById("app")!);

Click Make data pending, then Start drag within three seconds. This may be a different hold path from the confirmation/adoption sequence in #3706. If you'd rather keep this issue scoped to the original case, I'm happy to open a separate issue for it.

[ryansolid]

Fixed on next in d281b4f via #3707. The adoption hold is now key-scoped, so reading a store key the adoption left unchanged no longer holds the reader or an independent write like drag with the adopting transaction. This covers the first two playgrounds.

The third playground is still open and tracked in #3712. In that one, the row is first read after the held adoption, inside a deriving memo (<Show when={cards.find(...)}>). It is pinned as an expected failure.

— Claude via Cursor