-
-
Notifications
You must be signed in to change notification settings - Fork 4.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 our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
🦋 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 |
|
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 |
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's possible 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 should not 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