Skip to content

fix: unset_context when not already in an async derived#18295

Merged
Rich-Harris merged 3 commits into
effect-root-async-update-fixfrom
effect-root-async-update-fix-tweak
May 26, 2026
Merged

fix: unset_context when not already in an async derived#18295
Rich-Harris merged 3 commits into
effect-root-async-update-fixfrom
effect-root-async-update-fix-tweak

Conversation

@Rich-Harris

Copy link
Copy Markdown
Member

This is the fix in #18289 (comment), but saves us creating a bunch of microtasks

@changeset-bot

changeset-bot Bot commented May 26, 2026

Copy link
Copy Markdown

⚠️ No Changeset found

Latest commit: 43ab53b

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

@github-actions

Copy link
Copy Markdown
Contributor

Playground

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

@svelte-docs-bot

Copy link
Copy Markdown

@dummdidumm dummdidumm left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

approving but see the comment for small nit

if (batch === current_batch) unset_context();
});
}
if (unset) queue_micro_task(unset_context);

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Is the if (batch === current_batch) to check that it's still about our batch wrong or why did you remove it? Also I think the comment helps understand why we need this.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

Not wrong, just probably unnecessary — I can't make batch !== current_batch. I guess it's relatively harmless to include the check though

@Rich-Harris Rich-Harris merged commit 150fde9 into effect-root-async-update-fix May 26, 2026
17 checks passed
@Rich-Harris Rich-Harris deleted the effect-root-async-update-fix-tweak branch May 26, 2026 21:29
@Rich-Harris

Copy link
Copy Markdown
Member Author

On second thoughts, I think we should mostly revert this. Over on incremental-batches, I had a realisation the other day — ef4a077 — that we shouldn't be using $.save outside async deriveds.

We long ago decided that we shouldn't be restoring the batch context after an await outside the context of an async derived — i.e. $derived(await a + b) works, but this doesn't:

async function sum() {
  return await a + b;
}

let total = $derived(await sum());

We made that decision so that code couldn't start behaving inconsistently depending on whether the compiler could see it. But if that applies to dependency tracking, then it should apply equally to whether or not we're allowed to create effects. So the fact that we call $.save(...) for top-level (i.e. outside async deriveds) await expressions is a bug, and the $effect.pre in the tests added in this PR should result in an effect_orphan error, albeit with a bit more context.

@Rich-Harris

Copy link
Copy Markdown
Member Author

#18299

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.

2 participants