Bug in solid 2.rc6 store

[Azravos]

Describe the bug

A store created from a function (writable projection / createProjection), a write to a node is SILENTLY DISCARDED if a descendant of that node was written earlier in the same flush. A plain createStore(value) is correct.

The LLM proposed fix did seem to solve the issue when applied to the @solidjs/signals/../dev.js file. I've provided screenshot of this proposed fix in case it might help you to see/find the problem too.

Your Example Website or App

no

Steps to Reproduce the Bug or Issue

(AI generated reproduction):

import { createStore, createRoot, flush, snapshot, untrack, deep } from "@solidjs/signals";

const seed = () => [{ id: 1, selected: true, children: [{ id: 11, selected: true }] }];

function scenario(makeStore, order) {
  return createRoot(() => {
    const [store, setStore] = makeStore();
    untrack(() => deep(store));                      // materialize the projection
    setStore(prev => {
      const row = prev[0];
      if (order === "descendant-first") {
        row.children[0].selected = false;            // descendant
        row.selected = false;                        // ancestor  <-- discarded
      } else {
        row.selected = false;                        // ancestor
        row.children[0].selected = false;            // descendant
      }
    });
    flush();
    return JSON.stringify(snapshot(untrack(() => deep(store))));
  });
}

const plain      = () => createStore(seed());
const projection = () => createStore(() => seed(), []);
const EXPECTED   = `[{"id":1,"selected":false,"children":[{"id":11,"selected":false}]}]`;

for (const [name, make] of [["plain     ", plain], ["projection", projection]])
  for (const order of ["ancestor-first", "descendant-first"]) {
    const got = scenario(make, order);
    console.log(`${got === EXPECTED ? "PASS" : "FAIL"}  ${name}  ${order.padEnd(17)}  ${got}`);
  }

Expected behavior

See reproduce

Screenshots or Videos

No response

Platform

Windows

Additional context

No response

[javascript-unsafe]

Reproduced on 2.0.0-rc.6 and current next.

1. Create a writable projection with one row and one child.
2. Prime it with deep(store).
3. In one setStore, write row.children[0].selected = false and then row.selected = false.
4. Call flush(). The child remains false, but the row incorrectly returns to true.

The child fold path-copies its ancestors first, so the later parent fold's compare-and-swap sees an outdated slot and is skipped. The fix commits pending targets parent-first, with the reported case and all six three-write orderings covered in #3278.

[ryansolid]

Confirmed and fixed in fc7e626 — thanks for the excellent reproduction, it failed exactly as described (projection + descendant-first order discarded the ancestor write; all three other combinations passed).

Root cause: derived stores (and arrays) fold drafts on the clone path — at commit the pending backing is swapped in wholesale and the parent slot is re-pointed with a compare-and-swap against the pre-batch container. When a descendant of the same node was written earlier in the draft, the descendant's fold runs first and path-copies through the ancestor: it clones the ancestor's committed backing and re-points the parent slot at that clone. The ancestor's own fold then swapped in its stale draft-open-time clone, failed the parent CAS (the slot no longer held the pre-batch container), and the whole fold was orphaned — silently. Plain createStore(value) was immune because plain objects fold through the prototype-overlay path, which applies writes in place.

The fix merges the batch's written keys onto the already-privatized container instead of swapping (with a value-diff fallback when an array length write makes the written-key set unusable), so both folds compose. Your AI-suggested patch was pointing at the right neighborhood — the committed fix lands one layer deeper so descendant folds are preserved too, not just the ancestor's.

Regression tests cover both write orders across plain/derived stores, three-level nesting, deletes, and array length/push interleavings. Will ship in the next RC.