core

Problem An error thrown while notifying an effect leaves half-way through the notify buffer, so the rest of the batch is not notified and is instead delivered by the next unrelated write. The sync watcher throws from the dirty check inside , which escapes . 's other subscribers — including a component's render effect — are never notified, so the view keeps the previous content until some unrelated reactive write happens to flush the stale buffer: Clicking the button throws and the paragraph still says . Measured with the same app in : Root cause walks : Verification on the final revision: → 61 files, 1580 passed; the same command with only the source change reverted → 1576 passed with the 4 tests above failing (browser/e2e suites are not runnable in this environment). (), , and oxlint (strict config from ) are clean; oxlint reports the same single pre-existing finding on before and after. Out of scope The effect whose threw keeps its flag, so the next clears its flags without re-queueing it — in the repro above the sync watcher never fires again even after is restored to an object. That behaviour is identical before and after this change (measured on both revisions); it is a flags-lifecycle question in , not the notify buffer, so I left it alone here. Happy to look at it separately if that is useful. ref #15674

The browser ignores `Cannot read properties of null (reading '$clsFlags')form` branch from #15693.

In a Vapor template, `Failed to resolve component: keep-aliveisKeepAliveTagisTransitionGroupTag` already does.