Solid 2: reconcile repeats unchanged presence and holds unrelated updates

[GabbeV]

Describe the bug

Reconciling a plain store can hold an unrelated field's rendered update behind a pending action when a separate in expression observes a property that the action deleted. The incoming snapshot leaves that property absent, matching its already-staged presence.

Reproduction

One-button playground — preview 3ed3810, Tailwind disabled.

Click Build, then Run reproduction. The sequence is:

// Initial store: { a: { value: 0 }, b: { failed: true } }
const removeFlag = action(function* () {
  setState(draft => { delete draft.b.failed; });
  yield gate;
});

// In a later event, while removeFlag is pending:
setState(reconcile({ a: { value: 1 }, b: {} }));

The component separately renders state.a.value and "failed" in state.b; no memo combines them. The playground releases the action after 2.5 seconds.

Expected: Value: 1 appears while the deletion action remains pending.

Actual: Value: 0 remains until that action finishes, then becomes 1.

Controls and investigation

Verified in Chromium and Firefox, in development and production builds:

• Removing the separate presence expression allows the value to update immediately.
• Assigning failed = false instead of deleting it, and reconciling the same false, allows it to update immediately.
• Writing a.value = 1 directly instead of reconciling allows it to update immediately.

The suspected cause is the presence notification in notifyFold and notifyFoldTail. Value notifications compare old/new values, but the presence loops call setSignal for every observed key without comparing presence. The core joins the node's holding transaction before rejecting an equal value, so repeating false can entangle the reconciliation with the deletion action.

Adding an old/new presence comparison to both loops in an isolated test bundle prevents the hold. This is diagnostic evidence, not a fully validated patch.

Actual presence changes must still notify: deleting a prop override can select another merge source even when the resulting value is equal. This reproduction has no merge or provider switch; the suspected problem is the repeated absence-to-absence notification.

Version

solid-js and @solidjs/web from https://pkg.pr.new/mizulu/solid2/...@3ed3810 (Solid commit 3ed3810097bfc5e5d15829277b40315bbd2b5f74).

[GabbeV]

A related case also occurs in the setter value-notification path, with every property remaining present:

Minimal reproduction and reconciliation control, using preview 9a213bb. Click Build, then Run reproduction. Enable Use reconcile instead to compare after the first run finishes. Tailwind is disabled.

An action stages b.flag = false and waits. A later event writes only a.value and b.value:

setState(draft => {
  if (draft.a.value !== 1) draft.a.value = 1;
  if (draft.b.value !== 1) draft.b.value = 1;
  // No assignment to b.flag.
});

a.value remains rendered as 0 until the flag action finishes. Reconciliation with the same resulting data reveals 1 immediately. Omitting the b.value assignment also allows A to reveal immediately. This uses a plain store, without a derivation or optimistic store. Verified in Chromium and Firefox, development and production.

Tracing identifies notifyWrites re-notifying b.flag: the target's wk retains the earlier flag write until its backing commits. Writing b.value adds that key, and notification visits both. setSignal then joins the flag's holding transaction before rejecting the repeated false by equality. Reconciliation's value diff skips that repeat.

Suppressing just the repeated flag notification in an isolated diagnostic bundle removes the join. This suggests setter notification needs to distinguish keys written by the current setter from cumulative keys retained for the pending fold. Explicitly writing a held value again can still retain its intended join semantics; here the application does not make that repeated write.

[ryansolid]

Fixed on next by #3791 (924d909d9) — thanks for the clear reproduction.

Cause: L2's setSignal joins a held node's transaction before its equality gate, so the fold's unconditional presence write pulled the mainline tick into the action. Fix: notifyFoldTail now diffs presence old → neu and only writes what changed; applyAdopt materializes an overlay draft before capturing the diff base.

One residue is pinned as it.fails in the test file and will get its own fix: a later mainline setter re-notifying a held key from the cumulative written-keys set (fix direction: per-setter written keys).

Closing manually — auto-close did not fire because next is not the default branch.

— Claude via Cursor