fix: robustify async each blocks
#17126
Closing issues
Describe the bug
Hi,
When testing await in the script tag of a component, I found a bug that I can't understand. I don't know if this is really a bug or if I'm doing something wrong.
I'm simply using an await to simulate an async load in my components, which I display via an {#each} on my main component, with an "add one value" button to add an element.
- there is no problem if I add the elements one by one, waiting for them to load
- but if I click the button multiple times, the rendering may be broken :
- On a non-keyed
{#each}, some component are not correctly rendered (no children), and others are missing - On a keyed
{#each}, there are even more missing components!
- On a non-keyed
Exemple (there should be 10 numbered circles on each line) :
Reproduction
Reproduction : https://svelte.dev/playground/c7e416c4b97446468ee85f3abf4bc676?version=5.41.4
Logs
No error
System Info
REPL with Svelte 5.41.4
Severity
annoyance
Describe the bug
When I have pending async work happening (e.g. mounting an async component) I am getting strange and erroneous results while modifying state elsewhere.
See the reproduction for examples.
Reproduction
Reproduction: https://svelte.dev/playground/c0f672d625bb47f28808234647d8a5f3?version=5.42.2
This example contains a list of incrementing numbers which can be added to by clicking the button. Each list item will also cause an async component to be rendered.
If you rapidly click the "Add to list" button you will be appending to the list while async work in happening from mounting new the components.
When rapidly clicking you will observe
- The original list will temporarily have gaps in it
- The derived list showing the type of each element will have
undefinedwhere the gaps are
- The printed results should eventually reconcile
- Printing the lists as a text expression
{list}gives different results than printing inside of an#{each}block until the results reconcile
The primary issue here is (1) (and by extension (2)) where we temporarily have incorrect records. In the real world this leads to unexpected errors such as trying to access properties of undefined.
Logs
System Info
System:
OS: Linux 6.15 Arch Linux
CPU: (12) x64 AMD Ryzen 5 2600 Six-Core Processor
Memory: 4.59 GB / 15.54 GB
Container: Yes
Shell: 5.3.3 - /bin/bash
Binaries:
Node: 22.17.0 - /home/yung/.nvm/versions/node/v22.17.0/bin/node
Yarn: 1.22.22 - /usr/bin/yarn
npm: 10.9.2 - /home/yung/.nvm/versions/node/v22.17.0/bin/npm
pnpm: 10.13.1 - /home/yung/.local/share/pnpm/pnpm
Browsers:
Chromium: 139.0.7258.66
Firefox: 141.0
Firefox Developer Edition: 141.0
npmPackages:
svelte: ^5.41.4 => 5.41.4
Severity
blocking an upgrade
Pull request
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:
- run batch 1
- run batch 2
- run batch
- 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
arraymethod 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).
- 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
- batch 3 Circle.run completes, decrement 0, runs commit
- Does NOT rebase batch 2 because of same reasons as 4.
- 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:, 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
⚠️ No Changeset found
Latest commit: 34e0ac4
Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.
This PR includes no changesets
When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types
Click here to learn what changesets are, and how to add one.
Click here if you're a maintainer who wants to add a changeset to this PR
pnpm add https://pkg.pr.new/svelte@17126On reflection bug 1 should be solved differently - Rich is gonna take a stab at refactoring each.js. Only bug 2 should probably land from this PR.
restore each context upon commit - prevents run getting undefined boundaries
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 ;)