fix: avoid other batches running with queued root effects of main batch
#17145
Closing issue
Describe the bug
With hover preloading on and async enabled, it seems that conditional bind:this can somehow break reactivity for the application.
Minimal repro below. The select box uses the bind:this for absolutely nothing in the repro, but it still breaks. Remove the bind:this, disable preloading, or disable async and things behave as expected.
Reproduction
Logs
System Info
System:
OS: Windows 10 10.0.19045
CPU: (32) x64 AMD Ryzen 9 5950X 16-Core Processor
Memory: 31.45 GB / 63.89 GB
Binaries:
Node: 22.12.0 - C:\nvm4w\nodejs\node.EXE
npm: 10.9.0 - C:\nvm4w\nodejs\npm.CMD
Browsers:
Chrome: 141.0.7390.123
Edge: Chromium (140.0.3485.54)
Firefox: 144.0.2 - C:\Program Files\Mozilla Firefox\firefox.exe
Firefox Developer Edition: 137.0 - C:\Program Files\Firefox Developer Edition\firefox.exe
Internet Explorer: 11.0.19041.5794Severity
annoyance
Pull request
When #traverse_effect_tree runs, it can execute block effects, which in turn can create effects which are scheduled, which means queued_root_effects is now filled again. We didn't take that into account and assumed that in #commit we would have no queued root effects. As a result another batch could wrongfully run with the queued root effects of the main batch. That in turn can mean that skipped_effects is different on the other batch, leading to some branches not getting traversed into. As a result part of the tree is marked clean while further below batches are still not marked clean. That then breaks reactivity as soon as you schedule an effect in this still-not-clean sub tree, as it will not bubble all the way up to the root, since it comes across a not-clean branch, assuming something was already scheduled.
The fix is simple: Stash the queued root effects before rebasing branches.
Fixes #17118
Before submitting the PR, please make sure you do the following
- It's really useful if your PR references an issue where it is discussed ahead of time. In many cases, features are absent for a reason. For large changes, please create an RFC: https://github.com/sveltejs/rfcs
- Prefix your PR title with
feat:,fix:,chore:, ordocs:. - This message body should clearly illustrate what problems it solves.
- Ideally, include a test that fails without this PR but passes with it.
- If this PR changes code within
packages/svelte/src, add a changeset (npx changeset).
Tests and linting
- Run the tests with
pnpm testand lint the project withpnpm lint
Info
![changeset-bot[bot]](https://avatars.githubusercontent.com/in/28616?v=4)
🦋 Changeset detected
Latest commit: f573397
The changes in this PR will be included in the next version bump.
This PR includes changesets to release 1 package
| Name | Type |
|---|---|
| svelte | 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
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?v=4)
pnpm add https://pkg.pr.new/svelte@17145
Is this an argument for associating queued effects with the batch, rather than it being a global variable? It feels like it should only be possible to schedule an effect inside a batch (since an effect is scheduled as a result of a state change, which results in a batch being created if it doesn't already exist)... though this diff reveals that we currently do schedule effects outside batches:
-- a/packages/svelte/src/internal/client/reactivity/batch.js
++ b/packages/svelte/src/internal/client/reactivity/batch.js
@@ -819,6 +819,10 @@ function depends_on(reaction, sources, checked) {
* @returns {void}
*/
export function schedule_effect(signal) {
if (current_batch === null) {
throw new Error('here');
}
var effect = (last_scheduled_effect = signal);
while (effect.parent !== null) {I wanted to change that as part of an earlier refactor, because the global queued_root_effects skeeves me out, but I didn't quite manage it. Worth taking another run at it?
Ah, so it looks like at least one way you can schedule an effect with no current batch is if you're flushing an effect that contains a nested $effect. But with Batch.ensure at the top of schedule_effect, it works. Gonna noodle on this quickly
Hmm, can't quite get it to work. Does feel like the right direction though. Maybe I'll come back to it
Can we merge this one in the meantime to fix the bug?
yeah, fair enough. Added a note-to-self for later
fix: avoid other batches running with queued root effects of main batch
• Nov 12, 2025, 1:55 PMWhen `#traverse_effect_tree` runs, it can execute block effects, which in turn can create effects which are scheduled, which means `queued_root_effects` is now filled again. We didn't take that into account and assumed that in `#commit` we would have no queued root effects. As a result another batch could wrongfully run with the queued root effects of the main batch. That in turn can mean that `skipped_effects` is different on the other batch, leading to some branches not getting traversed into. As a result part of the tree is marked clean while further below batches are still not marked clean. That then breaks reactivity as soon as you schedule an effect in this still-not-clean sub tree, as it will not bubble all the way up to the root, since it comes across a not-clean branch, assuming something was already scheduled. The fix is simple: Stash the queued root effects before rebasing branches. Fixes #17118
Pro tip: You can prefix GitHub URLs of issues, PRs or discussions with svcl.dev/ to view them on this page! Also try it on a GitHub release ;)