Skip to content

Conversation

@Rich-Harris
Copy link
Member

Found while investigating #17409 — we don't unset current_batch after each iteration of $.run(...), which means that in certain cases changing state has no effect (as no new batch is created, and thus no flush occurs).

Additionally, it's possible for a batch to be committed (and therefore removed) while it still has dirty effects that were deferred (though only if the effect lives inside a boundary that is pending because of a different batch, which is something of an edge case). I think the fix here makes sense — when rebasing, add leftover effects to the remaining batch(es).

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
Copy link

changeset-bot bot commented Jan 5, 2026

🦋 Changeset detected

Latest commit: a88dded

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
Copy link
Contributor

github-actions bot commented Jan 5, 2026

Playground

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


for (const e of this.#dirty_effects) {
batch.#dirty_effects.add(e);
}
Copy link
Member

@dummdidumm dummdidumm Jan 5, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think this part is right. An effect would rerun multiple times as a result if multiple batches exist and resolve one after the other.

Also needs a comment because I at first thought this is all effects, not just leftovers

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, hadn't considered that it might cause effects to run multiple times. In most cases this would be harmless, but definitely suboptimal.

The correct thing, I think, would be to associate the leftover effects with the boundary rather than the batch, such that we can reschedule them when the boundary resolves. That would be a slightly meatier change so maybe I'll have a go at it in a different branch; if we want to merge this in the meantime in the interests of forward motion then I'm not too worried about the multiple runs thing, but understand if you'd prefer to hold off until we've explored that. I left a comment explaining what's going on here, with a TODO for the boundary effect thing

(about to get on a plane where I don't expect to have a) wifi or b) room to open my laptop, so may not get to this for a bit)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In the interest of ITG I'm fine with the interim solution

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

implemented the better solution #17424

Comment on lines +403 to +404
// TODO it would be better if the effects were associated with the
// boundary instead, and rescheduled when the boundary resolves
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
// TODO it would be better if the effects were associated with the
// boundary instead, and rescheduled when the boundary resolves
// TODO this is buggy when there are multiple pending batches and they resolve
// one after the other, leading to effects being executed more often than they should.
// It would be better if the effects were associated with the
// boundary instead, and rescheduled when the boundary resolves

@Rich-Harris
Copy link
Member Author

merged #17424, closing

@Rich-Harris Rich-Harris closed this Jan 7, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants