Skip to content

Conversation

@elliott-with-the-longest-name-on-github
Copy link
Contributor

Closes #17345 -- basically if you get the timings actually perfectly right it appears you get two copies of ALS, one which gets used for the first half of the first render and another that gets used for every subsequent render (including the second half of the first render, which causes the error). I have no idea how to test this other than running the reproduction in the original issue, which this fixes. (@florian-lefebvre, can you verify as well? Thanks!)

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 Dec 11, 2025

🦋 Changeset detected

Latest commit: 237fde0

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

Playground

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

@matthewp
Copy link

This still looks racey to me. Maybe it's not actually possible to have a race due to how this code is used that I don't have context for, but in isolation if init_render_context where called twice sequentially there would be 2 instances of als created. Maybe that doesn't matter because by the time its used there's only 1. I think what this code is really attempting to do is memoize the result of the full init_render_context() call.

@Rich-Harris
Copy link
Member

Yeah, maybe this?

/** @type {AsyncLocalStorage<RenderContext> | null} */
let als = null;

/** @type {Promise<void> | null} */
let als_promise = null;

export function init_render_context() {
	als_promise ??= import('node:async_hooks')
		.then((hooks) => {
			als = new hooks.AsyncLocalStorage();
		})
		.catch(noop);

	return als_promise;
}

@elliott-with-the-longest-name-on-github
Copy link
Contributor Author

lol, one step ahead of you

@matthewp
Copy link

Can confirm this fixes the Astro test that was breaking. Thanks a lot!

@elliott-with-the-longest-name-on-github
Copy link
Contributor Author

that somehow broke everything, brb

@Rich-Harris Rich-Harris merged commit 00459a1 into main Dec 12, 2025
18 checks passed
@Rich-Harris Rich-Harris deleted the elliott/als-race-condition branch December 12, 2025 03:23
@github-actions github-actions bot mentioned this pull request Dec 12, 2025
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.

5.44 breaks async rendering in Astro

4 participants