2.0.0-rc.4: flush() guard trips from the asyncWrite write-back on a screen with several async memos (no minimal reproduction)

[snowfluke]

Describe the bug

On 2.0.0-rc.4, the dev build throws Potential Infinite Loop Detected. from the flush() guard while a browser sits on one screen of our app. The page keeps working. The error reaches window.onerror, which is how our end-to-end suite catches it.

The guard is flush() counting its own iterations, in @solidjs/signals dist/dev.js around line 1882:

let count = 0;
while (scheduled$1 || activeTransition) {
  if (++count === 1e5) throw new Error("Potential Infinite Loop Detected.");
  globalQueue.flush();
}

So something reschedules work 100,000 times inside one flush.

Every occurrence carries the same three frames, and none of ours:

at flush                  (@solidjs/signals dev, the guard above)
at asyncWrite             (@solidjs/signals dev)
at result.then.syncError  (@solidjs/signals dev)

asyncWrite and the syncError continuation put it in the write-back of a settled async computation.

I am not claiming this is a framework defect. The guard lives in the framework, so it throws from there whoever caused the runaway. #2843 is the same message and its cause was application code. I am filing because I cannot attribute it after several days of work, and because of the production half below.

In production the guard is not there. dist/prod/core/scheduler.js has the same loop with no counter:

while (scheduled || activeTransition) {
    globalQueue.flush();
}

Whatever the cause, in a production build this does not throw. It spins. Pegged CPU, frozen tab, no error.

What I am asking for: which application patterns can drive asyncWrite to reschedule like this, and whether the guard could name the node it kept rescheduling instead of only reporting that it happened. The second one would let anyone hitting this attribute it themselves.

Your Example Website or App

https://github.com/PT-Perkasa-Pilar-Utama/testate

The app is public, but I have no minimal reproduction and I want to be honest about that up front rather than waste your time. The screen is a database grid at /projects/:slug/adapters/:id/tables/:table. It holds four async computations built on createMemo(async ...): a page of rows whose query a person controls through filters, sort, cursor and page size, plus the adapter, its schema, and a write-session presenter that refreshes the first one. It is the only screen in the product with that many, and the only one whose async memo takes a query that changes as fast as someone can click.

Relevant source: apps/web/src/lib/async.ts, apps/web/src/features/data/grid.presenter.ts, and the write-up in docs/upstream-solid-flush-loop.md.

Steps to Reproduce the Bug or Issue

I cannot give you a reliable recipe, and this is the honest state of it:

1. Run the full browser suite: bun run e2e. The suite drives a seeded instance through snapshots, checkouts, fixture imports and a job stream, then a crawler visits about thirty screens and clicks every control on each one.
2. About one run in four turns red on the grid screen with this error.

Counting the message in a run log instead of waiting for a test to fail: 4, 0 and 0 occurrences across three identical runs. So it fires more often than the red runs suggest, and single-run counts prove nothing about whether a change helped.

What does not reproduce it:

• A dedicated stress spec that drives the same screen's sort, filter, paging and read/write switch twenty times over with no wait between clicks, with and without a query the API rejects. Eight clean runs across three shapes, including one that walks a live server-sent-event stream first.
• The crawler run on its own, with no other project before it. Three clean runs.

The difference between a clean crawler run and a red one is only what ran before it in the same browser context. That points at accumulated state across thirty screens rather than anything the grid does by itself.

Expected behavior

I expected the flush to drain. Failing that, I expected the thrown error to tell me which computation kept rescheduling, so I could decide whether the fault was mine. Today the message says a loop happened and nothing about what looped, and the only frames are internal, so an application author has nowhere to start.

Screenshots or Videos

None that would help. The stack above is the whole observable signal.

Platform

• OS: macOS 26.6.2
• Browser: Chromium via Playwright 1.58.2 (browser build 1208)
• Version: solid-js and @solidjs/web 2.0.0-rc.4, @solidjs/signals 2.0.0-rc.4 transitively. Bun 1.4.0, Vite dev server.

Additional context

Prior art. #2843 is the same message on 2.0.0-beta.15, caused by isPending(() => latest(asyncMemo)) read in a user effect with no render effect subscribed to that memo. We use neither isPending nor latest, and that one was fixed in #2838 well before rc.4, so I do not think it is our case. It is the reason I am not calling this a framework bug.

Version history here. It happened on rc.3 as well. rc.4's note about a flush loop spinning forever on a pending store read (#3068) did not end it.

What I ruled out. The grid's only pure helper on that path. The grid's table-change effect, whose handler writes nothing its own source reads. Two server-sent-event effects elsewhere in the app, whose source value does not change when their list refreshes.

What I tried that did not fix it. I rewrote the data layer onto core primitives: refresh() on a memo instead of a version counter bumped to force re-runs, and a createMemo for a derived list that had been rebuilding a new array on every read. Both changes are right on their own merits and both are kept. Neither ended the loop.

Diagnostics. The reactivity-diagnostics skill shipped with rc.4 lists UNSTABLE_MEMO_OUTPUT as a pattern that makes the scheduler re-run more than it should. That is the closest description of anything we do, since an async memo returns a fresh promise per run by construction. Our suite dropped every console warning until yesterday, so no run has ever reported one. It keeps them now, and I will add a comment here if a run produces a diagnostic code.

Happy to run instrumented builds, patch a local copy of dist/dev.js with whatever logging you want, or try a branch. Tell me what to capture and I will capture it.

[snowfluke]

Found the cause. It is not what I guessed in the report above, and the fix is one line.

The defect

setSignal re-opens the node's transition before it checks whether the write changes anything:

if (el._transition && activeTransition !== el._transition)
  globalQueue.initTransition(el._transition);   // runs first
...
const valueChanged =
  !!(el._statusFlags & STATUS_UNINITIALIZED) || !el._equals || !el._equals(currentValue, v);
if (!valueChanged) return v;                     // and only then bails out

A Loading boundary keeps a boolean flag, and CollectionQueue._checkSources writes that flag on
every pass of a drain. When the flag already holds the value, the write does nothing, but it has
already re-armed the transition the node was stamped with. If that transition has already finished,
the drain loop sees a live transition again and goes round:

1. The drain loop sees activeTransition, so it calls globalQueue.flush().
2. transitionComplete returns true on its first line, since _done is already true. The
   transition completes and activeTransition becomes null.
3. Still inside that same flush, finalizePureQueue reaches checkBoundaryChildren, which reaches
   CollectionQueue._checkSources, which writes false over false.
4. setSignal re-opens the finished transition before discovering the write is a no-op.
5. The loop condition is true again. Back to 2.

Nothing recomputes anywhere in that cycle.

The measurements

I patched a local dist/dev.js to report scheduler state from inside the drain loop, then ran our
browser crawl until it tripped.

State sampled at iterations 200 to 204, every occurrence:

[FLUSH_PROBE] spin=200 tx=T1 done=true actions=0 txs=1 sched=false fx=0 lanes=0 :: n=0 empty
[FLUSH_PROBE] spin=201 tx=T1 done=true actions=0 txs=1 sched=false fx=0 lanes=0 :: n=0 empty

dirtyQueue empty (_min 1, _max 0), scheduled$1 false, both effect queues empty,
_pendingNodes empty, _asyncReporters empty, no lanes. The same transition object every pass,
tracked by identity through a WeakMap, with _done already true.

Counting what re-opens a transition, per drain:

[DEEP_DRAIN] passes=100000 distinct=1
[DEEP_DRAIN] n=99997 setSignal signal#? doneTx{?}

One node, on 99,997 of 100,000 passes. Capturing its writer:

[DEEP_WRITE] name=signal value=boolean:false subs=yes
  :: setSignal < CollectionQueue._checkSources < checkBoundaryChildren
     < checkBoundaryChildren < finalizePureQueue < GlobalQueue.flush < flush

The fix I am running

if (el._transition?._done === true) el._transition = null;

_done is only ever a forwarding object, which currentTransition follows, or the boolean true,
which ends the chain. So a stamp reading true is dead. resolveTransition already refuses a
finished transition on its override branch; the plain write path does not.

A guard inside initTransition does not work. I tried that first. Refusing the finished
transition there makes it open a fresh batch instead, and the drain keeps spinning with a new
transition identity on each pass. The guard has to stop the call, not redirect it.

Evidence that it is the fix

Both arms ran the same crawl with the same counters, differing only in that line. A run counts as
evidence only if the stale-stamp condition actually arose in it.

Arm	Runs meeting the condition	Drains over 25 passes	Runaways
unpatched	5 of 10	5 of 5	5 of 5
patched	6	0 of 6	0 of 6

In the unpatched arm the condition and the runaway matched ten times out of ten: every run that met
it span, every run that did not was clean.

Two notes

The production scheduler runs the same drain loop with no counter, so in a production build this
does not throw. It hangs.

My fix is at the layer that stopped it in our app, which may not be the layer you want. Clearing the
stamp when the transition completes, or refusing at the boundary's own write, would both be
defensible. Happy to measure any variant against the same suite.

[snowfluke]

Correction to my previous comment: the one-line fix I proposed is wrong, and I have withdrawn it. The diagnosis above still holds; the repair does not.

What went wrong

Dropping the dead stamp at the write site:

if (el._transition?._done === true) el._transition = null;   // do not do this

stops the drain from spinning, but it corrupts the pending-node bookkeeping:

RangeError: Invalid array length
  > queuePendingNode   dist/dev.js:1640
  > recompute          dist/dev.js:3645
  > runHeap
  > GlobalQueue.flush
  > flush

and on another path:

RangeError: Invalid array length
  > GlobalQueue.initTransition   dist/dev.js:1617
  > recompute                    dist/dev.js:3359
  > runHeap / GlobalQueue.flush / flush
  > asyncWrite / result.then.syncError

Measured over the same crawl, the error appears only with the patch, and only on runs that met the stale-stamp condition:

Build	Runs meeting the condition	Runaways	Invalid array length
unpatched	5 of 10	5 of 5	0 of 10 runs
patched	4 of 14	0 of 4	2 of those 4

So the stamp is not free to drop. Something downstream still expects the node to carry it, which I take to mean the node is genuinely still associated with that transition even after _done is set, and the real problem is elsewhere.

What I believe still stands

The diagnosis in my previous comment rests on direct measurement rather than on the repair working:

• The drain spins with an empty dirtyQueue, scheduled$1 false, both effect queues empty, no pending nodes, no async reporters, no lanes.
• It stays alive purely on activeTransition, which is the same object every pass, with _done already true.
• Exactly one node re-opens it, on 99,997 of 100,000 passes.
• The writer is CollectionQueue._checkSources under finalizePureQueue, writing false to a boundary flag that already holds false.
• setSignal re-opens the node's transition before it reaches its own valueChanged check, so that no-op write re-arms a finished transition.

What I got wrong was assuming the stamp was safe to clear once _done is true.

Two dead ends, so nobody repeats them

1. Guarding inside initTransition (refusing a transition with _done === true) does not help. It opens a fresh batch instead and the drain keeps spinning, with a new transition identity on each pass.
2. Clearing the stamp at the write site stops the spin but corrupts the pending-node arrays, as above.

I am not going to guess a third time. I have no local fix, and I am running unpatched. The reproduction recipe and the probe patches are available if any of it is useful to you, and I am happy to run any candidate against the same suite and report the same counters.

[ryansolid]

Root-caused and fixed in #3148 — your diagnosis was exactly right, and the probe data made this a fast fix. Two notes on where the fix landed relative to your one-liner: clearing at setSignal misses stamps whose _done is a forwarding object chasing to a dead end (merged transactions), and the async settle path can hand initTransition the same corpse through a different door. So the fix clears the stamp where every commit funnels (commitPendingNode, symmetric with the optimistic-stamp clear you noted in resolveTransition), and initTransition refuses a chased-dead transaction with a bare return — your measurement that a redirect-to-fresh-batch re-arms the loop is what shaped that. Your other ask is in too: the dev loop guard now reports what kept the loop alive (transition done-state, queue counts, last staged node) — your case would have printed done=true, pending=0 on the first throw. The production build still has no counter, but with the stamp lifecycle fixed the corpse class is closed at the source. Thank you for an outstanding investigation.

[ryansolid]

Fixed on next (ca16891, PR #3148), completing what #3143 started. Two halves: commitPendingNodes now clears each node's _transition stamp when its pending value commits (symmetric with optimistic stamps — a committed value needs no affiliation), and initTransition refuses a transaction whose _done chain ends true, since setSignal re-opens a node's stamped transaction before the value-equal bail — a dangling stamp let any later write, even a no-op, resurrect the finished transaction, and a boundary flag rewritten every finalize pass then spun the drain loop (dev threw the guard; production hung). Since your report had no minimal reproduction, each layer is pinned directly, and the dev loop guard now reports what kept the loop alive — transition done-state, queue counts, the last staged node — so if any third path to this state exists, the next report can name it instead of starting from a bare 'Potential Infinite Loop Detected'.