[P1] 2.0.0-rc.6: A nested derived-store write disconnects ancestor property observers

[brenelz]

Describe the bug

In a derived store created with createStore(seed, seed()), editing a nested child can change an ancestor's proxy identity and disconnect existing property observers. An effect watching store.row.selected receives the initial true, but after a child write and then row.selected = false, it never receives false. Direct reads return the updated value.

Priority assessment: P1. Existing reactive bindings silently remain stale after ordinary nested edits, despite the store accepting the later write.

Platform and version

• Source checkout: next at 472232bf; package version 2.0.0-rc.6.
• macOS, Node.js v25.1.0, Vitest 4.1.6. No browser or DOM required.
• Verified against the tracked @solidjs/signals source, rather than a downloaded npm release.

Reproduction

In a checkout of the commit above with dependencies installed, save the following as packages/signals/tests/store/derived-ancestor-observers.test.ts and run from the repository root:

pnpm --dir packages/signals exec vitest run tests/store/derived-ancestor-observers.test.ts

import {
  createRenderEffect,
  createRoot,
  createStore,
  flush,
  untrack,
} from "../../src/index.ts";

describe("subscriptions after descendant writes", () => {
  for (const derived of [false, true]) {
    it(`${derived ? "derived" : "plain"} store keeps an ancestor observer connected`, () => {
      const seed = () => ({ row: { selected: true, child: { count: 0 } } });
      let dispose!: () => void;
      const seen: boolean[] = [];
      const [store, setStore] = createRoot((d) => {
        dispose = d;
        const pair = derived ? createStore(seed, seed()) : createStore(seed());
        createRenderEffect(
          () => pair[0].row.selected,
          (value) => {
            seen.push(value);
          },
        );
        return pair;
      });
      try {
        flush();
        const originalRow = untrack(() => store.row);
        setStore((draft) => {
          draft.row.child.count = 1;
        });
        flush();
        setStore((draft) => {
          draft.row.selected = false;
        });
        flush();
        expect(untrack(() => store.row.selected)).toBe(false);
        expect.soft(seen).toEqual([true, false]);
        expect(untrack(() => store.row === originalRow)).toBe(true);
      } finally {
        dispose();
      }
    });
  }
});

Expected and actual behavior

After writing row.child.count = 1, flushing, then writing row.selected = false and flushing:

Check	Expected	Actual for derived store
Direct store.row.selected read	false	false
Values received by the observer	[true, false]	[true]
store.row === originalRow	true	false

The matrix produces 1 failing derived-store case and 1 passing plain-store control. Both the notification and identity assertions fail in the derived case.

Source analysis

privatizeCommitted() registers the cloned ancestor in storeNextLookup, while reads for a derived store resolve targets through its family map. The next read can therefore wrap the clone as a new target, leaving existing subscribers attached to the previous target.

Related context: #3271 concerned a descendant-first write discarding an ancestor's value in the same flush. Here the writes are separated by flush(), the final value is correct, and the defect is lost observer connectivity and proxy identity. This still fails on the commit above, which includes the #3271 fix.

[ryansolid]

Confirmed and fixed in d50e855 — this one was a one-line registration bug.

Root cause: when a descendant write path-copies through an ancestor, privatizeCommitted clones the ancestor's committed backing and re-points the parent slot — but it registered the clone only in the global store lookup. Derived stores (and projections/optimistic stores) resolve children through their own family map, so the next store.row read missed the map, wrapped the clone as a brand-new target — new proxy identity, fresh nodes — and every subscription on the original target was orphaned. That's why your selected observer went silent after the child.count write, and why it only happened in the derived form (plain stores resolve through the global lookup, where the clone was registered).

The clone now registers in the target's own map; proxy identity and observers survive privatization. Regression test pins both forms plus identity: packages/signals/tests/store/privatization-observer-identity.test.ts.

Predated the #3271 fix (shipped in rc.6); in the next release. Thanks for the trio of reproductions — all three of these were real and are now pinned by tests.

— Claude via Cursor