Skip to content

fix: preserve dirty status of deferred effects #16487

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.

Sign up for GitHub

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

Jump to bottom
Merged
merged 5 commits into from
Jul 24, 2025
Merged

fix: preserve dirty status of deferred effects #16487

merged 5 commits into from
Jul 24, 2025
+101 −21

Conversation

Rich-Harris
Copy link
Member

Ironically, the part of #16482 that fixed the infinite loop bug in #16403 introduced an even worse infinite loop that made remote functions unusable. I have learned, for the 19th or so time, that it is absolutely not safe to mark_reactions when triggering a batch re-run.

It turns out we (which in this case is the royal 'we') were doing something rather silly: we were queueing all leaf effects when traversing the tree, not just the DIRTY/MAYBE_DIRTY ones. In the common case that's fine, because they get flushed immediately and they get filtered with is_dirty, but if the effects are deferred (because async work is happening) then on the next run they are all marked DIRTY and re-executed.

This PR makes everything somewhat more efficient. Firstly, it only queues effects that are not CLEAN. (We can't use an is_dirty check during traversal, because that can cause deriveds to be re-evaluated with inconsistent data.) Secondly, it notes whether they were DIRTY or MAYBE_DIRTY at the time of deferral, and restores that status to prevent unnecessary re-runs of MAYBE_DIRTY effects.

I wasn't able to whittle the remote functions infinite loop thing down to a test case, but I verified the fix locally which will have to do for now as it's 1am and I'm supposed to be demoing this stuff on YouTube tomorrow.

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:, or docs:.
  • 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 test and lint the project with pnpm lint

@changeset-bot changeset-bot
Copy link

changeset-bot bot commented Jul 24, 2025 •
edited
Loading

🦋 Changeset detected

Latest commit: 51f24a3

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

@github-actions GitHub Actions
Copy link
Contributor

Playground

pnpm add https://pkg.pr.new/svelte@16487

@Ocean-OS Ocean-OS merged commit 53417ea into main Jul 24, 2025
15 checks passed
@Ocean-OS Ocean-OS deleted the async-prevent-loop branch July 24, 2025 05:48
@github-actions github-actions bot mentioned this pull request Jul 24, 2025
Merged
dummdidumm added a commit that referenced this pull request Jul 24, 2025
@dummdidumm
chore: don't do effect scheduling unnecessarily
3e87bb3 
mini-cleanup post #16487 - we don't need to do the work of scheduling an effect that's already dirty which means it already scheduled its root effect to run
@dummdidumm dummdidumm mentioned this pull request Jul 24, 2025
Merged
dummdidumm added a commit that referenced this pull request Jul 24, 2025
@dummdidumm
chore: don't do effect scheduling unnecessarily (#16489)
46d3261 
mini-cleanup post #16487 - we don't need to do the work of scheduling an effect that's already dirty which means it already scheduled its root effect to run
@cdcarson
Copy link

cdcarson commented Jul 25, 2025 •
edited
Loading

I'm going to post this here because, in decades of trying to break javascript and write the worst stuff ever, I have never, ever seen this error...

Uncaught SyntaxError: Too many parameters in function definition (only 65534 allowed)

...and I suspect it's related to this issue/set of commits. I'm not saying Svelte is at all to blame. I'm just trying to debug what is probably really bad state management in our (my company's) code. It looks like stuff is being recursively spread into a function, until such time as the limit is reached.

I can't share the code that causes this, but if you like I can try to come up with a minimal repro. LMK, and thanks for all your work!

@dummdidumm
Copy link
Member

Sounds like a .push(...spread) somewhere that's collecting a loooot of arguments (at least that's what happened in Svelte 4 some years ago when someone managed to write a giant component which broke the compiler)

@cdcarson
Copy link

Ok, I'll check our code first for that. Thanks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@Ocean-OS Ocean-OS Ocean-OS approved these changes

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
4 participants
@Rich-Harris @cdcarson @dummdidumm @Ocean-OS
pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy