await Promise.all inside $derived waterfall warning

[ageorgeh]

Describe the bug

When awaiting a Promise.all inside a $derived I can see the await_waterfall warning. I'm possibly misunderstanding the warning but I don't think it should warn about it.
The warning can be seen in the REPL console upon first load.

In my project I was also getting await_reactivity_loss from the same code that produced this warning which actually had an impact on the app. I haven't been able to reproduce that in a REPL but they're possibly related

Reproduction

https://svelte.dev/playground/7150c39aa545498bba86de0a18506707?version=5.55.1

Logs

[svelte] await_waterfall
An async derived, `broken` (App.svelte:29:16) was not read immediately after it resolved. This often indicates an unnecessary waterfall, which can slow down your app
https://svelte.dev/e/await_waterfall

System Info

System:
    OS: Linux 6.18 cpe:/o:nixos:nixos:26.05 26.05 (Yarara)
    CPU: (16) x64 13th Gen Intel(R) Core(TM) i5-13400F
    Memory: 32.52 GB / 62.65 GB
    Container: Yes
    Shell: 5.3.9 - /run/current-system/sw/bin/bash
  Binaries:
    Node: 24.13.0 - /nix/store/9cyx2v23dip6p9q98384k9v06c96qskb-nodejs-24.13.0/bin/node
    npm: 11.6.2 - /nix/store/9cyx2v23dip6p9q98384k9v06c96qskb-nodejs-24.13.0/bin/npm
    pnpm: 10.28.0 - /nix/store/q182xhmnqzff17cdg90hcp44ljgvqqr7-pnpm-10.28.0/bin/pnpm
    bun: 1.3.10 - /etc/profiles/per-user/alex/bin/bun
  Browsers:
    Chrome: 146.0.7680.153
    Firefox: 149.0
    Firefox Developer Edition: 149.0

Severity

annoyance

[verysleepylemon]

This looks like a false positive in the await_waterfall heuristic. The warning fires when an async derived value is not read "immediately" after resolving — but with Promise.all, the derived can only resolve after all promises complete simultaneously, so there's inherently a gap between when the derived is scheduled and when it resolves (while all the inner promises are in flight). The scheduler sees this gap and mistakes it for an unnecessary sequential waterfall.

The distinction the heuristic should make:

• True waterfall: const a = await p1; const b = await p2(a); — b waits for a serially
• Parallel (not a waterfall): const [a, b] = await Promise.all([p1, p2]); — both run in parallel

Promise.all flattens what would be a waterfall into a concurrent fan-out, which is exactly the right pattern to use. The warning for this case is misleading.

Workaround: If the warning is only cosmetic and doesn't affect correctness, you can suppress it. If you're also seeing await_reactivity_loss from this code, that is a separate and more serious issue — reactivity loss means Svelte can't track which signals the derived depends on across the await boundary, which can cause stale/missed updates. In that case, restructuring to eagerly capture reactive values before the await (see https://svelte.dev/e/await_reactivity_loss) would help.

[dummdidumm]

Investigated this a bit and this warning is somewhat correct. You are creating the top level blocking async derived, and then you're awaiting another normal derived in the template. Because normal deriveds are lazy this other async work isn't starting until the await expression in the template. You could start it earlier by adding a read of working directly after its declaration (for which you'd have to svelte-ignore another static warning) but even then the warning is still shown, which I would say could count as a bug, since the underlying promise has already started, and we should see that.

[ageorgeh]

I also just found that if you add an await in the template in front of broken it fixes the warning.
Not sure why.