fix(signals): lane authority — merged hold, reveal-on-flight, INV-11, override supersession with provenance (#3335 #3334 #3330 #3331)

[ryansolid]

Four lane-authority fixes in @solidjs/signals, one commit per issue, each with its changeset, plus a fifth commit that pins every rule against its optimistic-store twin and a sixth from review (the A15 reveal carve-out re-ruled, a provenance gap). All pre-existing on next. Stacked on #3337 (latest-held-till-flush): the A28 write path and the #3336 store rules are the base these compose with; the base retargets to next when #3337 merges.

#3335 — merged lane hold is per node, not per transaction

laneHeld looked up a lane's _pendingAsync nodes in its own transaction's _asyncReporters. Lanes merge across transactions (#2912), so after a merge the root's transaction knew only one member's observations and the other member's async no longer held the merged reveal. New waitingTransition(node) finds the live transaction blocked on a node, whichever recorded it; laneHeld asks per node.

#3334 — a reveal holds on the lane flight it discovers, regardless of stamp

Two halves of one tear: read()'s pending branch carved out nodes pending in another transaction for stale readers and showed their committed value (the stamp is bookkeeping, not evidence the inputs are held — they may already be lane-revealed); and handleAsync's settle re-entry entered the lane owner's transaction, folding the waiting reveal into the owner's still-running action. The reader now throws (A15); the landing enters the waiter.

#3330 — a lane recompute compares against the slot it publishes (INV-11)

A lane (OPT-dirty) recompute compared against a transaction-staged _pendingValue while publishing to _value, called an identical result "unchanged", and revealed the override without its derivation (v=1 d=0). The gate now compares against the slot the run publishes to. Found alongside: laneReadsCommitted replayed lane readers at commit even when the staged value already equalled the committed one — a duplicate frame; recorded only when the commit changes what was read.

#3331 — own-source arrival supersedes the override, with action provenance

Per the ruling ("a new value from the source should remove the optimism immediately… folded into the parent transition"): a differing arrival marks the node superseded — tracked readers see the staged truth, the lane cascade is demoted and re-derives as held transaction work (downstream async restarts now, no waterfall), the override's own downstream flight is inert — while untracked reads and the applied frame keep the override until commit. Equal arrivals confirm silently. Scope covers the sync-wrapper shape (createOptimistic(() => asyncMemo())) — "if the source recomputes it doesn't matter if it is async or not" — with a same-batch ordering guard.

Provenance. Two rapid actions on one node merge into one transaction, and the older action's refetch can land after the newer override. That answer must not leak back in ("getting it not to flicker was super important"). _overrideOwner is post-merge and can't tell the actions apart, so the scheduler carries the running action's invocation sequence (origin) through each action slice and the flush that ends its window; every flight captures it at registration and its landing propagates under it. The override stamps it; a differing arrival from an older action holds silently to the commit. Mainline (no action) is always current. The original no-double-flicker pin is unchanged and green; the "second action while first still in flight" pin had its second resolver repaired (it used to orphan action 1, so its final assertions passed against a transaction that never closed) and is expected to the same rule.

Store twins (fifth commit)

Every rule above is pinned against the equivalent optimistic-store shape (tests/store/lane-authority-twins.test.ts). #3335 and #3334 already held; #3330 and #3331 did not:

• 2.0.0-rc.7 Optimitstic set after short delay in action doesn't propagate through memo #3330 twin. An adoption under a live transaction now holds on optimistic families too — a sync derive adopting truth under the action's transaction is held truth, not lane business. Unheld, handlers read the swapped-in backing early, latest() inverted, and the optimistic write compared equal to it and wrote no override; notifyOptimisticWrites now judges against the view readers see. A held adoption stages its nodes under the transaction at the outermost setter exit (stageHeldAdoptions) so the commit promotes silently instead of re-running every subscriber against a frame the lane already published. Plain-store reconcile inside an action holds the same way; a key first read under a held adoption is born holding (one stageHeldKey shared with 2.0.0-rc.7 spooky action at a distance because of lazy latest computed creation #3336's fold case).
• 2.0.0-rc.7 async downstream of optimistic delays reveal of final result #3331 twin. The authoritative landing on an override-covered store node (setSignal under projectionWriteActive) dispatches to the engine (_landOnOverride → supersedeOverride) instead of staging silently; supersededRead serves committed truth once a mainline landing has committed ahead of the revert.
• Core, surfaced by the twin and reproduced with a plain signal: a reader that first links to a node while another transaction holds a staged write read committed and never learned of the commit (commits are silent). heldFromStale records such readers for the transaction's commit replay, skipping effects the transaction itself computed.
• Composition with A28 (rebase): the async landing's supersession decision runs at the write's promotion (promoteUnflushed's override arm hands the node to supersedeOverride, still under the flight's provenance). A settle that reverts optimism re-derives its contested effects (2.0.0-rc.7 render effect depending on non async values from two concurrent updates commit with the wrong data #3322) after the revert, with the gated replay — ahead of the heap run the truth is committed but the overrides still display, and the re-derive composed the two (the 2.0.0-rc until doesnt entangle the update resolving it with the action update #3164 tear; surfaced by deep() over an optimistic store).

Review follow-ups (sixth commit)

From GabbeV's review on this PR:

• A15 reveal corollary, re-ruled. 2.0.0-rc.7 Issue 3305 can still happen for optimistic and latest values while fixed for normal signals #3334 removed read()'s pending-branch carve-out outright, so a new reader of a memo whose input write is itself still held waited for the landing — though showing the committed pair introduces no inconsistency (parallel transactions; effects don't entangle; React 19.3 stopped entangling the same shape). The carve-out returns, gated on input visibility: a stale reader of a node pending in another transaction shows committed, does not entangle, and is recorded for that transaction's commit replay (heldFromStale). It is refused — the reader holds — when the committed value would tear against the frame: the flight's inputs were published while it was pending (CONFIG_INPUTS_PUBLISHED, set by commitPendingNode when a commit leaves the node in the air, fix(signals): hold conditional reveals on existing async work #3305; cleared when the node next enters pending fresh), the node rides a live lane (_laneLive → resolveLane; optimistic / latest, 2.0.0-rc.7 Issue 3305 can still happen for optimistic and latest values while fixed for normal signals #3334), or the node is uninitialized. The initialized-memo pin and its store twin return to "show v0, then v1"; every 2.0.0-rc.7 Issue 3305 can still happen for optimistic and latest values while fixed for normal signals #3334/fix(signals): hold conditional reveals on existing async work #3305 hold pin still passes.
• Replay hygiene the carve-out surfaced: an effect recorded in _gatedSubs that later recomputes under the recording transaction is applied by the commit itself — the stale recording published the frame twice. recompute drops it at its start; a lane's committed-view read re-records during the run.
• Provenance gap (2.0.0-rc.7 async downstream of optimistic delays reveal of final result #3331): a same-value re-prediction by a newer action took the fast path without renewing _overrideStamp, so the older action's slow source superseded a value the user had just re-confirmed (corrective downstream refetch, pending flip). The fast path renews the stamp to a newer origin.
• GabbeV's two "pre-existing" publication failures (a revealed reader never catching up; a conditional reader staying hidden) were fixed by the fifth commit's heldFromStale recording and are now pinned in tests/reveal-carve-out.test.ts, alongside a replacement-flight-over-published-inputs shape and a retired-lane shape.

Docs / bytes

SPEC A15 lanes corollary, A17 amendment, A18 supersession + scope/ordering/provenance, 2026-09-09 re-ruling log; INTERNALS-ASYNC §1–§3, §5 INV-11, late readers, contested post-revert; INTERNALS-STORE §3 adoption under a live transaction. Core floor: 22,866 / 22,950 (22,737 before the rebase onto #3337's hot-path fix and A28-for-optimistic commits, +79 B from the base) — a conscious bump over #3337's 22,331 (+~160 B lane-authority seams, +126 B store-twin seams (_landOnOverride dispatch, heldFromStale), +~40 B contested post-revert, +99 B gated carve-out). .size-limit.js scenarios reconciled for the stack with per-scenario notes (e.g. core floor 8.32 → 8.54 KB brotli; the isPending/latest scenario carries the engine, +450 B; hydrating + every store family 28.30 → 28.35 KB after #3337's affects walk fix, +44 B here).

Verification

Rebased on #3337 @ 027fda2 (itself on next @ 4935c7d). #3337's promoteUnflushed moved into core.ts; this branch's override arm (_supersedeOverride) is re-applied there, after the A28(5) _promoteOverride arm for parked optimistic writes. signals 1767 passed / 1 skipped · solid 595 · web 734 · tsc clean · full pnpm build · npm run size green locally on both branches.

[changeset-bot]

🦋 Changeset detected

Latest commit: fae8b76

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 11 packages

Name	Type
@solidjs/signals	Patch
test-integration	Patch
@solidjs/web	Patch
@solidjs/babel-plugin	Patch
@solidjs/compiler	Patch
@solidjs/diagnostics	Patch
@solidjs/element	Patch
@solidjs/h	Patch
@solidjs/html	Patch
solid-js	Patch
@solidjs/universal	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[GabbeV]

AI review based on the context where I found these issues:

The JSX repros for #3330, #3331, #3334 and #3335 behave as expected on 03334af0. There is a reproducible gap in the new provenance protection, relative to the PR’s stated rule that an older action’s response must not restart work beneath a newer override.

The graph is essentially the existing provenance test:

const source = createMemo(() => fetchSource());
const [value, predict] = createOptimistic(source);
const details = createMemo(() => fetchDetails(value()));

// Observe value and details, plus isPending(details).
// Initially everything has settled at 0.

const save = action(function* (guess, responseReady) {
  predict(guess);
  yield responseReady;
  refresh(source);
});

Here fetchSource and fetchDetails are controlled requests. Each details request resolves to its captured input. The following sequence illustrates the difference:

// A and B have separate responseReady gates.

save(5, responseReadyA);
flush();

save(5, responseReadyB);
flush();

// Resolve the optimistic details requests and settle.
// The displayed frame is 5:5, with isPending(details) === false.

// Release A's gate, allowing its refresh(source) to start.
// Resolve that source request with 2.
// Keep B's gate unresolved.

At that point:

// Intended by the older-response protection:
latest(value);      // 5
isPending(details); // false
// No details(2) request.

// Actual:
latest(value);      // 2
isPending(details); // true
// A details(2) request starts.

The main displayed value/details frame remains 5:5; this is unnecessary corrective work and a reappearing pending indicator, not a claim that the main displayed value immediately reverts to 2.

The control is particularly useful: change only A’s prediction from 5 to 3, keeping B’s prediction at 5. Then the old response is correctly suppressed: no details(2) request, and the pending indicator stays false.

This reproduces in both dev and prod. The cause appears to be the same-value fast path:

if (!valueChanged) {
  // Joins the action's lifetime...
  return value;
}

// ...but the newer invocation is only recorded down here.
extension._overrideStamp = origin;

The second action renews the lifetime of the override without renewing its provenance. An isolated experiment updating _overrideStamp in that early-return path removes the failure and preserves the distinct-value control. That’s causal evidence for the missing bookkeeping, rather than validation of a complete fix.

One separate semantic question concerns the changed initialized-memo test. Simplified:

const [a, setA] = createSignal(0);
const shared = createMemo(() => fetchValue(a()));
const [show, setShow] = createSignal(false);

// One existing reader observes shared.
// Another renders show() ? shared() : "hidden".

After shared has published "v0":

setA(1);
flush();
// shared's new request is pending; the source update is held.

setShow(true);
flush();

The previous test allowed the new reader to show the existing committed "v0". The amended test keeps it hidden until "v1" is ready.

The #3334 repro establishes why the reveal must wait when the input has already been published. When the source update itself is still held, what consistency violation would showing its corresponding committed memo value introduce? Is the broader wait intentional to support the single-graph implementation, or is it a conservative consequence of removing the transaction-stamp exception?

[GabbeV]

Reacts behavior for the show during load case interestingly changed behavior in 19.3 and now don't entangle because of them enabling parallel transitions:
19.2.0
19.3.0

[GabbeV]

Follow-up AI review: two additional ordinary-signal publication failures still reproduce on this PR's head 03334af0, the updated #3337 head ba538c28, and next at a1ed7f37. These are pre-existing failures, not regressions introduced by this PR.

Both were independently reproduced with core primitives and with compiled JSX in jsdom using real timers, without the fuzzer's hooks or completion probes. The core reproductions below were checked on both PR heads.

Each case uses a fresh root and starts after its initial async values have settled. observe represents a separate render effect writing to a plain output record:

const rendered = {};
const observe = (name, read) =>
  createRenderEffect(read, value => { rendered[name] = value; });
const delay = (ms, value) => new Promise(r => setTimeout(r, ms, value));

A: a reader revealed during a held update never catches up when it commits.

const [input, setInput] = createSignal(0);
const [show, setShow] = createSignal(false);
const shared = createMemo(() => input());
const slow = createMemo(() => delay(1000, shared()));
const fast = createMemo(async () => shared());

observe("input", input);
observe("show", show);
observe("A", () => `${input()}:${slow()}`);
observe("B", () => show() ? `${input()}:${fast()}` : "hidden");

After initialization, run from an event handler:

setInput(2);
await delay(500);
setShow(true);
await delay(2000);

// Expected: input=2, show=true, A="2:2", B="2:2"
// Actual:   input=2, show=true, A="2:2", B="0:0"

During the hold, B reveals the coherent committed pair 0:0. The failure is that B stays there after the slow request resolves and input/A publish 2/2:2. This does not depend on choosing whether the initial reveal should wait or show committed data; the final view is inconsistent after all work finishes.

B: one conditional reader remains hidden after the shared visibility signal commits true.

const [input, setInput] = createSignal(0);
const [show, setShow] = createSignal(true);
const details = createMemo(() => delay(1500, input()));

observe("input", input);
observe("show", show);
observe("A", () => show() ? input() : "hidden");
observe("B", () => show() ? details() : "hidden");

After initialization, run from an event handler:

// Queue the hide before setInput queues Solid's flush.
Promise.resolve().then(() => setShow(false));
setInput(3);
await delay(500);
setShow(true);
await delay(500);
setInput(0);
await delay(2000);

// Expected: input=0, show=true, A=0,        B=0
// Actual:   input=0, show=true, A="hidden", B=0

Both readers initially hide. The attempt to show them again waits while details is pending; input is then changed back to 0. Once all requests have settled, show publishes true and B publishes 0, but A remains hidden. There are no optimistic/latest reads or Loading boundaries in either case.

Posting these together because they seem adjacent to the reveal/publication work. Their root causes have not been established, and they need not be folded into this PR; they can be split into separate issues if that is easier to track.

[GabbeV]

Another potentially related case: removing the last observer of pending async work doesn't seem to release the update waiting for it.

After the initial value settles, click the button. After 500ms, Show removes the only reader of details, but input remains at 0 until the now-unobserved request finishes at 1500ms.

I'd expect input to publish 2 when that reader disappears, since nothing displayed needs the pending result anymore. Could this be the removal side of the changing-observers problem addressed here?

import { createMemo, createSignal, Show } from "solid-js";

const delay = (ms, value) =>
  new Promise(r => setTimeout(r, ms, value));

export default function App() {
  const [input, setInput] = createSignal(0);
  const [show, setShow] = createSignal(true);
  const details = createMemo(() => delay(1500, input()));
  const forwarded = createMemo(() => details());

  return <>
    <button onClick={async () => {
      setInput(2);
      await delay(500);
      setShow(false);
    }}>Run</button>
    <p>Input: {input()}</p>
    <p>Show: {String(show())}</p>
    <Show when={show()}>
      <p>Details: {forwarded()}</p>
    </Show>
  </>;
}

AI-assisted investigation reproduced this with compiled JSX in jsdom on next (a1ed7f37), #3337 (ba538c28), and this PR (03334af0), independently of the fuzzer that found it. The shared root cause is only a hypothesis; happy to split this into an issue if it's separate.

[GabbeV]

Made playgrounds for them if you want to try them more easily.

https://s.olid.uk/id/UnddL9GdQhOxx7vp3_EU8A
https://s.olid.uk/id/kynw9OOMRcyPWzafZnXKBQ
https://s.olid.uk/id/0CwjsfLWQmyWPJ8IyuE_7w

Testing the third one made me realize that that one might be working as intended. It is just that we could resolve faster given the observer is removed but there is no inconsistency in not doing it.

[coveralls]

Coverage Report for CI Build 34574149299

Warning

No base build found for commit 451f087 on latest-held-till-flush.
Coverage changes can't be calculated without a base build.
If a base build is processing, this comment will update automatically when it completes.

Coverage: 71.842%

Details

• Patch coverage: No coverable lines changed in this PR.

Uncovered Changes

No uncovered changes found.

Coverage Regressions

Requires a base build to compare against. How to fix this →

---

Coverage Stats

Relevant Lines:	1007
Covered Lines:	772
Line Coverage:	76.66%
Relevant Branches:	790
Covered Branches:	519
Branch Coverage:	65.7%
Branches in Coverage %:	Yes
Coverage Strength:	15.03 hits per line

---

💛 - Coveralls

[codspeed-hq]

Merging this PR will not alter performance

✅ 151 untouched benchmarks

---

_{Comparing fix/lane-authority (b6d266e) with latest-held-till-flush (b722898)}

[ryansolid]

All four threads addressed in 4638b34 (sixth commit on this branch). Thanks for the quality of these — the causal isolation on the stamp and the React 19.2 → 19.3 comparison both saved real time.

Same-value fast path / _overrideStamp — confirmed and fixed exactly where you pointed: the early return now renews the stamp when the incoming origin is newer. Your two-same-value shape is pinned in spec-async-semantics.test.ts ("a same-value re-prediction by a newer action renews the override's provenance"): after A's source answers 2 with B's gate still open, latest(value) stays 5, isPending(details) stays false, no details(2) request; B's later answer still supersedes. The distinct-value control still passes.

The initialized-memo question — ruled your way. You had it right: when the source update is itself still held, showing the corresponding committed memo value introduces no inconsistency. The broad wait was a conservative consequence of removing the transaction-stamp exception in #3334, not a semantic goal. Ryan's call, informed by the 19.3 change you linked: we support parallel transactions, effects don't entangle, and we would rather get the semantics right now than ship an intermediate break. The carve-out is back, gated on input visibility rather than on the stamp:

A stale (render) reader of a node pending in another transaction shows the committed value, does not entangle, and is recorded for that transaction's commit replay — unless the flight's inputs are visible: they were published while it was pending (CONFIG_INPUTS_PUBLISHED, set when a commit leaves the node in the air — your #3305 shape), the node rides a live lane (optimistic / latest — the #3334 shape), or the node is uninitialized. Then the reader holds.

The stamp comparison was never the evidence; the mark is. The amended test and its store twin return to "show v0, then v1"; every #3334 / #3305 hold pin still passes.

Cases A and B — both were fixed by the fifth commit's heldFromStale recording (a reader that first links to a node while another transaction holds its write is recorded for that transaction's commit replay; before, commits were silent to it, which is exactly the "revealed reader never catches up" and "conditional reader stays hidden" you saw). I bisected your reproductions to confirm that commit alone flips them, and they are now pinned as written in tests/reveal-carve-out.test.ts (real timers, same mid-frame and final frames). The re-ruled carve-out surfaced one more thing worth knowing about: a recorded effect that later recomputes under the recording transaction is applied by the commit itself, so the stale recording published the frame twice — recompute now drops it at its start.

Third case (removing the last observer) — agree with your own conclusion: working as intended. Releasing the update early when its last reader leaves would be an optimization with no coherence benefit, and it is not one we want to take on here.

Core floor moved 22,638 → 22,737 for the gated carve-out; the size-limit scenarios on both PRs are reconciled with per-scenario notes.

— Claude via Cursor

[ryansolid]

Superseded by #3370, which is this same series re-based directly onto next so the lane-authority fixes can ship in this rc independently of #3337 (the A28 write path, which is being held for more thought).

Same six fix commits and changesets. The only re-port is where this branch composed with A28: the async landing's supersession decision dispatches eagerly from asyncWrite (as next does) instead of at promoteUnflushed, and the store twins carry only the held-adoption born-holding case — #3336's held-fold case stays with #3337. Floor is 21,994 → 22,457 on next (vs. +485 B here on the stack). Review comments on this PR were addressed in the sixth commit, which carried over unchanged.

When #3370 merges, #3337 rebases onto it and moves the _supersedeOverride dispatch back into promoteUnflushed's override arm — the shape this branch (@ fae8b76) already has.

— Claude via Cursor