[bug] Bad rendering using await in component
#17033
Development PRs
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
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.
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
Issue
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
Info
Not a "fix", but as a temporary workaround, you can use $state.raw
https://svelte.dev/playground/e9a3e19c221d4a49a546c136c6f70039?version=5.41.4
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 ;)