fix: avoid other batches running with queued root effects of main batch

[dummdidumm]

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:, or docs:.
• 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 test and lint the project with pnpm lint

[changeset-bot]

🦋 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]

Playground

pnpm add https://pkg.pr.new/svelte@17145

[Rich-Harris]

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?

[Rich-Harris]

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

[Rich-Harris]

Hmm, can't quite get it to work. Does feel like the right direction though. Maybe I'll come back to it

[dummdidumm]

Can we merge this one in the meantime to fix the bug?

[Rich-Harris]

yeah, fair enough. Added a note-to-self for later