solid

Summary Fixes #2761, #2762 and #2813 — three ways a single throwing effect (or cleanup) can break an app on 2.0.0-beta.15. The first two share a root cause: when an effect throws and nothing handles the error, the exception unwinds mid-queue. The queue array is already detached at that point, so sibling effects queued behind the thrower are lost (#2762). And if the effect wrote a signal earlier in the same flush, stays true with no microtask armed, so every later write short-circuits in and the app is dead until something calls manually (#2761). Rather than patching the individual unwind paths, this removes the mechanism: unhandled effect errors no longer throw through the scheduler at all. They go through a small funnel () that collects them during a drain and rethrows the first one from once the drain completes (extra ones are 'd so they don't disappear). Outside a drain it throws in place, so creation-time behavior is unchanged. I also split "work is pending" from "a drain microtask is armed" (new flag), so even if a drain dies for some unforeseen reason, the next write can always arm a fresh one instead of trusting a flag that lied. #2813 is a separate bug the scheduler stall was hiding: invokes the previous cleanup before clearing and before the . A throwing cleanup is therefore never detached (every later run re-invokes the dead cleanup and the effect body never runs again), never reaches the (error boundaries can't see cleanup errors), and never reaches the (the dev strict-read guard leaks, and every untracked read in the app starts warning ). The fix is to detach the cleanup to a local before calling it, inside the . Same reorder in and the error handler's cleanup callback. The observable changes, in one list: sibling effects queued after a throwing effect now run (#2762) a signal write followed by a throw in the same flush no longer permanently stalls scheduling (#2761) unhandled effect errors surface from after the drain completes, instead of aborting it mid-queue a throwing cleanup costs one round instead of permanently disabling its effect (#2813) error boundaries now catch cleanup errors (previously impossible — the throw bypassed 's catch) the dev-only cascade of false positives after a cleanup throw is gone Two commits, one per root cause, each green on its own. One existing test changed ( reentrant-flush): it pinned the old abort behavior where the nested callback and a pending write were silently dropped; the guardrail error still throws, but queued work now drains. Why that test's expectations changed (the only existing-behavior change in the suite) The test's purpose — the reentrant-flush guardrail throws — is untouched, as are the two writes after the call (the throw still aborts the user callback at that statement, so is , not ). What the old secondary assertions pinned was the #2762 unwind itself, observed from an callback: the nested , registered before the violation, was silently discarded (), and the effect stayed permanently stale against a write that had already committed — read while the effect had seen and would never be told otherwise (). That's an internally inconsistent reactive graph frozen into a test. This change is forced by any fix to #2762, not by this particular design: even the most minimal per-callback containment in produces the new values. Keeping the old expectations would require special-casing the guardrail error to still unwind the drain — i.e. deliberately preserving one live instance of the bug. Two judgment calls reviewers may want to weigh in on: when several effects throw in one drain, the first is thrown and the rest are 'd (an or an hook would be alternatives, but both change public API), and errors now surface at the end of the drain rather than mid-flush (no existing test cared, but it is observable). Full disclosure: I wrote this with the help of an AI assistant (Claude Fable 5) and reviewed every line before pushing. All new tests were written first and confirmed failing on the unfixed code, and the bugs and fixes were both verified against the published beta.15 npm package, not just this repo. How did you test this change? 10 new unit tests across / / / , each verified red on the pre-fix code before applying the fix. The strict-read one is telling: reverting the fix fails it plus 11 unrelated tests in the same file, because the leaked flag poisons everything that runs after it. , then (uncached): all 19 tasks green — signals 782, solid-js 416, web 409. Commit 1 was also tested in isolation (778/778). Node scripts against the built dist using only microtask scheduling (no manual ), replicating the StackBlitz repros from the three issues: the error surfaces once, siblings survive, later writes keep flushing, the wedged effect recovers, and no warnings appear. The same scripts run against the published package reproduce all three failures — the fixes target what is actually shipped.

Describe the bug If a user effect throws during a flush, later effects already queued in the same batch are permanently skipped. The thrown error escapes, which is expected enough, but the remaining queued callbacks are lost because the queue is detached before iteration. One important wrinkle: this is order-dependent. If the throwing effect is queued before a sibling effect, the sibling never observes the update. If the sibling is queued first, it runs before the throw. Your Example Website or App https://stackblitz.com/edit/solidjs-templates-thqrgu5x?file=src%2FApp.tsx Steps to Reproduce the Bug or Issue 1. Open the StackBlitz repro and the browser DevTools console. 2. On mount, the console shows sibling effect saw: 0 (expected). 3. Click . 4. The console shows an uncaught Error: boom from the first effect, and the sibling effect never logs 1. Expected behavior A throwing effect may propagate its error, but it should not permanently discard unrelated queued effects from the same flush. After the error is caught, either the remaining queued work should already have run, or it should still be available to drain. Screenshots or Videos _No response_ Platform OS: macOs Browser: chrome Version: 2.0.0-beta.14 Additional context _No response_

Describe the bug If a callback writes a signal and then throws during the same flush, the scheduler gets stuck and no further updates run until you manually call flush(). A throw alone does not cause this particular stall. Your Example Website or App https://stackblitz.com/edit/solidjs-templates-vmutpnzg?file=src%2FApp.tsx Steps to Reproduce the Bug or Issue 1. Click “1. break the scheduler (throws once)”. The console shows an uncaught error (boom). 2 - Click “2. increment b” several times. Actual: b = … never updates again — the UI is frozen. Expected behavior After the one-time error from step 1, step 2 should keep updating the display (b = 101, b = 102, …). Reactivity should recover automatically; only the throwing effect should fail, not the whole app. Screenshots or Videos _No response_ Platform OS: macOs Browser: Chrome Version: 2.0.0-beta-14 Additional context Root cause The stall requires write + throw in the same flush, not a throw alone: 1. sets and queues a microtask to . 2. During that flush, before effects run, is reset to when the dirty queue is empty (). 3. The effect calls → sets again, but does not queue a new microtask because is already (). 4. The effect then throws; the flush aborts with still and no pending microtask. 5. Every later write hits in — reactivity is dead until something calls manually. A throw without an in-flush signal write does not leave stuck this way. The app can still update on the next user action. Suggested fix direction Ensure the effect-running phase clears or re-arms on abort (e.g. around effect execution, or re-queue a microtask when a flush exits early with pending work).