sveltejs / svelte · Issue No. 18662
Requires compilerOptions.experimental.async: true.
Awaiting multiple async resource together with Promise.all:
const [a, b, c] = $derived(await Promise.all([one(), two(), three()]));
…re-executes the underlying work without bound instead of settling.
Inside a <svelte:boundary> it eventually crashes with effect_update_depth_exceeded; without one, it silently re-executes forever in the background.
It does not reproduce on a bare, first-ever mount(). It requires the component to be reached either via hydration or a reactive swap of siblings within an already-mounted tree (as SvelteKit's client-side router does on-navigation).
I hit this in a real app via SvelteKit's remote-functions: three queries awaited together via Promise.all on a page. It worked on a non-hydrating SSR-only load but hung/crashed on every client-side navigation to it. In my experience both in real code and the repro, it typically doesn't occur with 2 parallel awaited resources, but does with 3 or more.
I was able to repro in vanilla Svelte by mirroring the following two properties of remote functions:
then backed by a lazily-started reactive promise.set(...) shortly after it resolves (single-flight refresh – a query response also carries a fresh copy of the query's own result).Playground: Async derived Promise.all over remote-query-like thenables
pending…, then content in Queries.svelte after 350msfailed snippet:Crashed: effect_update_depth_exceeded Maximum update depth exceeded. This typically indicates that an effect reads and writes the same piece of state https://svelte.dev/e/effect_update_depth_exceeded
effect_update_depth_exceeded
Maximum update depth exceeded. This typically indicates that an effect reads and writes the same piece of state
https://svelte.dev/e/effect_update_depth_exceeded
System:
OS: macOS 26.6.1
CPU: (18) arm64 Apple M5 Pro
Memory: 3.47 GB / 64.00 GB
Shell: 5.9 - /bin/zsh
Binaries:
Node: 24.16.0 - /Users/ken/.local/state/fnm_multishells/2425_1786199624106/bin/node
npm: 11.13.0 - /Users/ken/.local/state/fnm_multishells/2425_1786199624106/bin/npm
pnpm: 11.5.3 - /Users/ken/.local/state/fnm_multishells/2425_1786199624106/bin/pnpm
Browsers:
Chrome: 151.0.7922.138
Firefox: 153.0.4
Safari: 26.6
annoyance
Relay reads this issue against the repository's contribution signals: the files it is likely to touch, how the maintainers triage work this size, and what the first contribution would exercise.
The full analysis for this issue is still being assembled. Until then, the description above and the thread on GitHub are the most reliable context.