Fixes #17033 Fixes #17050

This one's hell, and has revelead three different bugs:

Bug 1

commit in an each could happen long after the original context of the block effect is gone. That means get_boundary() in run might not get the correct active effect, maybe it's even null at that moment. To fix it I think we need to capture then restore the context. Loads of tests failed with that approach, so I added another capture-restore within the commit function itself but there's still one test failing - still trying to find out why.

Bug 2

Each blocks get out of order because of race conditions and block effects not rescheduling when they should. Reproducible by clicking fast three times on the button in the reproduction of #17033. This is what happens:

1. run batch 1
2. run batch 2
3. run batch
4. batch 1 completes, wants to rebase batch 2/3.
   • Does update and run batch 2 first. That reruns each block because each blocks rely on the newer values (because of proxy each entry is a separate source). Since each's array method is not time traveling it's always the value of whatever batch ran last. Rerun also causes reinit of Circle.svelte because each logic destroys the old one
   • Does NOT run batch 3 because no overlap according to our "depends on distinct values" logic (since each block just reran and now has more dependencies on it so false negative).
5. batch 3 Circle.run completes, decrement 0, runs commit
   • Does NOT rebase batch 2 because of same reasons as 4.
6. batch 2 Circle.run completes, decrement 0, runs commit -> wrong end result

The reason for this is that block effects can change dependencies after a rerun and so a subsequent batch rebase could have a false positive or negative effect reschedule. To fix it we need to split up the rebase logic into two stages: First collect all effects of all batches that should rerun, then run them in a second loop.

Bug 3

each state is not properly time-travel-ready. Something goes wrong for keyed each blocks in #17033 still. The problem is that fine grained proxy means some array entries may appear undefined for subsequent runs when they shouldn't, but no further insights yet and no idea how to fix yet.

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

As noted in #17126, each blocks are a little buggy when there's async stuff involved. #16977 fixed a bunch of stuff around async blocks/branches, but excluded each blocks because, well, they're complicated. But the time has come to deal with it.

As the commit messages suggest this is very WIP — a bunch of tests are failing, and while it fixes part of the problem (item effects and the fallback effect both need to be created immediately inside the block effect, not later upon commit), it doesn't yet fix the problems relating to overlapping async batches. But I thought I'd open the PR in this unfinished state anyway. Pleasingly, so far it's a net reduction in code and complexity.

• fixes #17033
• fixes #17074

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

This fixes an awkward bug with each blocks containing await, especially keyed each blocks.

If you do array.push(...) multiple times in distinct batches, something weird happens — to the each block, the array looks this...

[1]

...then this...

[undefined, 2]

...then this...

[undefined, undefined, 3]

...and so on. That's because as far as Svelte's reactivity is concerned, what we're really doing is assigning to array[0] then array[1] then array[2]. Those (along with array.length) are each backed by independent sources, which we can rewind individually when we need to 'apply' a batch. When it comes to sources that actually are independent, this is useful, since we apply the changes from batch B to the DOM while we're still waiting for a promise in batch A to resolve. But in this case it's not ideal, because you would expect these changes to accumulate.

In particular, this fails with keyed each blocks because duplicate keys are disallowed (assuming the key function doesn't break on undefined before the duplicate check happens).

This PR fixes it by stacking batches that are interconnected. Specifically, if a later batch has some (but not all) sources in common with an earlier batch, then when we apply the batch we include the sources from the earlier batch, and block it until the earlier batch commits. When the earlier batch commits, it will check to see if doing so unblocks any later batches, and if so process them.

In the course of working on this I realised that SvelteSet and SvelteMap aren't async-ready — will follow up this PR with ones for those.

Fixes #17050