Uh oh!
There was an error while loading.Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork4.6k
fix: abort and reschedule effect processing after state change in user effect#16280
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to ourterms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
Uh oh!
There was an error while loading.Please reload this page.
Conversation
changeset-botbot commentedJul 2, 2025 • edited
Loading Uh oh!
There was an error while loading.Please reload this page.
edited
Uh oh!
There was an error while loading.Please reload this page.
🦋 Changeset detectedLatest commit:8d82339 The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
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 |
|
dummdidumm commentedJul 2, 2025 • edited
Loading Uh oh!
There was an error while loading.Please reload this page.
edited
Uh oh!
There was an error while loading.Please reload this page.
This is a good solution IMO - it doesn't yet work for Adding similar logic to |
Good catch. Rather than making changes to |
I've skipped the |
cf2ff5e
intomainUh oh!
There was an error while loading.Please reload this page.
abtinturing commentedJul 7, 2025 • edited
Loading Uh oh!
There was an error while loading.Please reload this page.
edited
Uh oh!
There was an error while loading.Please reload this page.
I was having a problem similar to#16072 and after pulling the latest update, it's still there. It happens only if there is an I wasn't able to reproduce exactly that scenario, but I got another issue when trying to recreate it, which also is running code before the As for my original problem, all I can provide are these screenshots since I couldn't reproduce, but this is just for reference, the REPL above is enough to trigger the issue: And here's where that error is thrown, which as you can see, that code shouldn't even be running given the condition of the |
@abtinturing please create a new issue. |
Fixes#16072. It's a real edge case, hence the convoluted nature of the test, but it'spossible for a state change in one effect to cause a subsequent already-scheduled effect to run even though the second effect would be destroyed if the effect tree was being processed from the root.
The solution, I think, is to abort the processing of effects if a state change occurs. We can schedule the remaining effects and start again from the top; this will ensure that any dirty branches (i.e. a now-falsy
if
containing an effect with a now-broken reference) are updated before their children. Within each flush of the effect tree, predictable order is preserved.We need to distinguish between user effects and non-user effects, since element bindings can result in state changes, and these shouldnot cause flushing to be aborted (they are guaranteed to run before the effects that depend on the changed state, so this is not a problem).
Before submitting the PR, please make sure you do the following
feat:
,fix:
,chore:
, ordocs:
.packages/svelte/src
, add a changeset (npx changeset
).Tests and linting
pnpm test
and lint the project withpnpm lint