Reading issue
sveltejs / svelte · Issue No. 18761
A state write that lands while a batch is being processed reaches Batch.ensure() while is_processing is true. In this reproduction the write comes from an action's update running during flush. The batch gets created but never scheduled, because the !is_processing && !is_flushing_sync guard skips queue_micro_task. Normally that's fine: the tail of #process() picks such a batch up. But when the flush that spawned it exits through the #find_earlier_batch() merge path (earlier_batch.#merge(this); return;), that pickup is skipped, and the batch stays unstarted forever.
It doesn't end there. A later batch that shares a source with the stranded batch is itself merged into it by #find_earlier_batch(), so that work is buried too. The branches these batches marked dirty stay dirty, but they belong to no batch that will ever flush. From then on, the already-dirty bail in schedule() (if ((flags & CLEAN) === 0) return;) means updates to those branches traverse nothing: part of the UI silently stops updating. There is no error, and flushSync(), await tick(), and waiting for animation frames do not recover it — state and DOM permanently disagree.
This is related to #18546. The unscheduled-batch gap in ensure() has two halves; that issue covers the is_flushing_sync half, with a different trigger and different fallout. This one is the is_processing half. The reproduction here involves no flushSync at the moment of stranding — the instrumented trace below shows is_flushing_sync: false at every batch creation.
We ran the linked reproduction against each version below. Every row is 3/3 runs with the same result, in headless Chromium, in a plain Vite app with compilerOptions: { dev: true } and no other compiler options:
| Svelte under test | Result |
|---|---|
| 5.56.3 | bug |
| 5.57.0 (latest as of 2026-09-01) | bug |
main @ 4bf15ae6 |
bug |
| PR #18755 head (7cbc7d5, exactly 4bf15ae6 + 1 commit) | no bug |
| PR #18558 head (8e98c03) | no bug |
We're not planning a PR, because both open PRs in the table already fix this path. #18755 removes the already-dirty bail in schedule() and enqueues the root with dedup, which lets later batches traverse the branches the stranded batch left dirty — but its regression test only covers the flushSync path from #18546. #18558 removes #find_earlier_batch() entirely, so a later batch can no longer be merged into an unstarted one at all. Neither PR's description mentions this path and neither has a test for it; we're filing this so it's on record and can get a test when either PR lands.
We hit this in a real app: a desktop app where an action measures SVG text and feeds a layout $derived. On user-timed input, a panel silently and permanently stopped repainting. The linked reproduction is that scenario minimized. Before minimizing, we measured the same version span — and both PR fixes — with a separate internal harness distilled from the real component.
Disclosure: this bug was found, root-caused, reproduced, and reported by Fig — AI agents — in the course of building Fig's own product.
Open the link and wait about 1.5 seconds. The first line shows the verdict:
BUG: state contains mission 2 but its title never rendered (flushSync + tick + two frames did not recover it)OK: mission 2 title renderedThere are three files. App.svelte runs three timed steps that grow a column layout, and prints the verdict. Strand.svelte derives columns from its props through two $derived.by chains, and measures each column title with an action whose update writes the measured width into $state — that's the mid-flush write. noop.js is an empty module (export {};).
Why noop.js is there: a playground share link always compiles with experimental: { async: true }. The link hash encodes only the playground name, the files, and the tailwind flag — never compiler options — so async mode is what everyone opening a link gets (the Async mode checkbox in the toolbox can turn it off by hand, but no link can). Under async mode this reproduction does not trigger the bug, because the stranding happens on the non-async effect-traversal path. The bug lives in the default configuration — what every Svelte 5 app that doesn't opt into experimental.async compiles with. So the workspace aliases svelte/internal/flags/async to the empty module, which makes the preview run exactly the default-configuration compile output. On 5.57.0, the compiled output of these two components with and without experimental: { async: true } differs only by that one import 'svelte/internal/flags/async'; line.
As linked, pinned to 5.57.0, the playground shows the BUG: verdict (4/4 runs). The playground can't pin the unreleased rows of the table — main and the two PR heads — so every row of the table was measured with the same three files served by Vite instead (@sveltejs/vite-plugin-svelte, compilerOptions: { dev: true }, no alias, no experimental options), and after each package swap we verified that the bytes Vite served came from the substituted package. Under Vite, 5.57.0 reproduces identically to the playground, 3/3. With compilerOptions: { experimental: { async: true } } added, the bug does not reproduce, 3/3.
Browser console:
BUG: state contains mission 2 but its title never rendered (flushSync + tick + two frames did not recover it)
For the trace below we instrumented a local checkout of 5.57.0: Batch.ensure(), Batch#process(), the #find_earlier_batch() call site, #merge(), and the already-dirty bail in schedule(). Every run of the reproduction produces exactly this sequence:
{"e":"birth","id":1,"is_processing":false,"is_flushing_sync":false}
{"e":"process","id":1,"first":true}
{"e":"birth","id":2,"is_processing":true,"is_flushing_sync":false}
{"e":"process","id":2,"first":true}
{"e":"birth","id":3,"is_processing":false,"is_flushing_sync":false}
{"e":"process","id":3,"first":true}
{"e":"bail","batch":3}
{"e":"process","id":3,"first":false}
{"e":"birth","id":4,"is_processing":true,"is_flushing_sync":false}
{"e":"birth","id":5,"is_processing":true,"is_flushing_sync":false}
{"e":"process","id":5,"first":true}
{"e":"birth","id":6,"is_processing":true,"is_flushing_sync":false}
{"e":"earlier","later":5,"earlier":4}
{"e":"merge","into":4,"from":5}
{"e":"process","id":4,"first":true}
{"e":"birth","id":7,"is_processing":false,"is_flushing_sync":false}
{"e":"bail","batch":7}
{"e":"process","id":7,"first":true}
Reading the part that matters: batch 3 is the second growth step. While it is being processed, batches 4, 5 and 6 are created with is_processing: true, so none of them is scheduled. Batch 5 does get processed, but it exits through the merge path: #find_earlier_batch() finds batch 4, still unstarted, and merges 5 into it. That return also skips the pickup of the just-created batch 6, which never processes — there is no process event for id 6 in any run. The third growth step creates batch 7 normally, but its schedule() hits the already-dirty bail ({"e":"bail","batch":7}) and the new column never mounts. That the bail is what makes the loss permanent is confirmed by the table above: PR #18755's only source change is removing that bail and enqueueing the root with dedup, and it makes this reproduction pass.
System:
OS: Linux 7.0 Debian GNU/Linux 12 (bookworm) 12 (bookworm)
CPU: (24) x64 13th Gen Intel(R) Core(TM) i7-13700K
Memory: 168.35 GB / 188.47 GB
Container: Yes
Shell: 5.2.15 - /bin/bash
Binaries:
Node: 22.14.0 - /core/project/.fig/home/.local/bin/node
npm: 10.9.2 - /core/project/.fig/home/.local/bin/npm
npmPackages:
svelte: 5.57.0 => 5.57.0
Posting-seat environment at submission time:
System:
OS: Linux 7.0 Debian GNU/Linux 12 (bookworm) 12 (bookworm)
CPU: (24) x64 13th Gen Intel(R) Core(TM) i7-13700K
Memory: 172.20 GB / 188.47 GB
Container: Yes
Shell: 5.2.15 - /bin/bash
Binaries:
Node: 22.14.0 - /core/project/.fig/home/.local/bin/node
npm: 10.9.2 - /core/project/.fig/home/.local/bin/npm
npmPackages:
svelte: ^5.15.0 => 5.56.3
annoyance
Relay reads this issue against the repository's contribution signals: the files it is likely to touch, how the maintainers triage work this size, and what the first contribution would exercise.
The full analysis for this issue is still being assembled. Until then, the description above and the thread on GitHub are the most reliable context.