For index accessors stay stale after an optimistic reorder when the mutation is a router action

Run the provided TypeScript reproduction and compare the router action path with the plain async and nested Solid action variants. Trace the interaction among the router action/query, createOptimisticStore, and For index accessors; the fix is done when the settled list reads b:0 a:1 c:2 and the optimistic overlay is removed after the action.

Describe the bug

When a Solid action reorders rows in an optimistic store optimistically and then calls a router action, the rows move but For's index accessors do not, and they never update afterwards. After the router action finishes and the query behind the store refetches, the list shows the new order with the old indexes (b:1 a:0 c:2) until the page is reloaded. Any code that uses i() then targets the wrong row. In a kanban board this disabled the "move up" button on the wrong card and computed wrong drop positions.

Every piece of the repro is needed. The same reorder recovers correctly (indexes are stale only during the transition, then correct) when:

• the mutation is a plain async function followed by revalidate(getCards.key) instead of a router action,
• the mutation is a nested Solid action that calls revalidate(getCards.key),
• the optimistic store derives from a plain createMemo(async …) instead of a router query.

Without the optimistic write (just the router action, then the list re-renders from the refetched query), the indexes are also correct.

Your Example Website or App

The component below. It needs no server functions: the query and the router action are both client-side.

Steps to Reproduce the Bug or Issue

With @solidjs/[email protected], solid-js/@solidjs/web 2.0.0-rc.9 and @solidjs/[email protected] (client start mode):

import { action as routerAction, createRouter, query, useAction } from "@solidjs/router";
import { action, createMemo, createOptimisticStore, For, Loading } from "solid-js";

type Card = { id: string; order: number };
let db: Card[] = [{ id: "a", order: 0 }, { id: "b", order: 1 }, { id: "c", order: 2 }];
const wait = (ms: number) => new Promise(r => setTimeout(r, ms));

const getCards = query(async () => {
  await wait(20);
  return db.map(c => ({ ...c }));
}, "cards");

const swapOnServer = routerAction(async () => {
  await wait(150);
  const [x, y] = [...db].sort((p, q) => p.order - q.order);
  db = db.map(c => (c.id === x.id ? { ...c, order: y.order } : c.id === y.id ? { ...c, order: x.order } : c));
}, "swap");

function Cards() {
  const data = createMemo(() => getCards());
  const [cards, setCards] = createOptimisticStore(() => data(), [] as Card[]);
  const sorted = () => [...cards].sort((x, y) => x.order - y.order);
  const call = useAction(swapOnServer);
  const swap = action(function* () {
    setCards(list => {
      const [x, y] = [...list].sort((p, q) => p.order - q.order);
      const t = x.order;
      x.order = y.order;
      y.order = t;
    });
    yield call();
  });
  return (
    <>
      <button onClick={() => swap()}>swap</button>
      <ul>
        <For each={sorted()}>{(r, i) => <li>{r.id}:{i()}</li>}</For>
      </ul>
    </>
  );
}

const Router = createRouter({ routes: [{ path: "/", component: Cards }] });

export default function App() {
  return <Router>{props => <Loading fallback={<p>…</p>}>{props.children}</Loading>}</Router>;
}

1. Load the page. The list reads a:0 b:1 c:2.
2. Click swap. The list immediately reads b:1 a:0 c:2.
3. Wait. It still reads b:1 a:0 c:2 indefinitely.

The same happens when the router action is a "use server" function returning reload({ revalidate: [getCards.key] }), returning nothing, or returning a value, and with singleFlight: false. It also happens in the production build, and on 2.0.0-next.28.

Expected behavior

b:0 a:1 c:2 once the action settles, as with the plain-async and nested-Solid-action variants above.

Screenshots or Videos

No response

Platform

• OS: macOS 15 (arm64)
• Browser: Chromium 151 (Playwright headless shell)
• Node: 24.21.0
• Versions: @solidjs/router 2.0.0-next.30 (also 2.0.0-next.28), solid-js/@solidjs/web/@solidjs/signals 2.0.0-rc.9, @solidjs/vite-plugin 3.0.0-next.44, Vite 8.3.0

Additional context

I have not traced the root cause. The stale value is For's index accessor (solid-js), but only the router action path leaves it stuck: a nested Solid action doing the same mutation and revalidate recovers. A related symptom in the same setup: if the router action resolves without changing the data (for example it returns new Error("rejected"), the documented validation pattern), the optimistic store overlay itself is never dropped and keeps showing the rejected reorder. That may share a cause; I can file it separately.