fix: abort running obsolete async branches
#18118
Closing issue
Describe the bug
I got a bunch of this warning when updated Svelte to 5.55.3. This is caused by some weird interactions between a couple of shadcn-svelte, bits-ui, svelte-sonner components and page.url. Created a reproduction as requested by @dummdidumm.
Reproduction
Logs
[svelte] derived_inert Reading a derived belonging to a now-destroyed effect may result in stale valuesSystem Info
[email protected]
[email protected]Severity
annoyance
Pull request
We shouldn't continue executing async work where we know the surrounding branch is destroyed already, it can leave to noisy "derived inter" warnings or even runtime errors ("cannot stringify symbol" when running a template effect with an uninitialized source). Neither should we warn about waterfalls on an already-destroyed async effect.
Fixes #18097 (though strictly speaking that particular instance is also fixed by #18117 which fixes the underlying cause for the reruns; this one is necessary in itself though, as shown by the new test)
Info
![changeset-bot[bot]](https://avatars.githubusercontent.com/in/28616?v=4)
🦋 Changeset detected
Latest commit: 9d4dd20
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
![svelte-docs-bot[bot]](https://avatars.githubusercontent.com/u/23617963?v=4)
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?v=4)
pnpm add https://pkg.pr.new/svelte@18118We shouldn't continue executing async work where we know the surrounding branch is destroyed already, it can leave to noisy "derived inter" warnings or even runtime errors ("cannot stringify symbol" when running a template effect with an uninitialized source). Neither should we warn about waterfalls on an already-destroyed async effect.
Fixes #18097 (though strictly speaking that particular instance is also fixed by #18117 which fixes the underlying cause for the reruns; this one is necessary in itself though, as shown by the new test)