Await reactivity loss warning when consuming the same state in two different queries

[hugo-hsi-dev]

Describe the bug

OUTDATED:
The warning appears when I try to update global state that is accessed in a component and passed to a remote query. I have tried contexts and URL search params for my solution of global application state, both of which result in the same warning. Interestingly, this issue seems to only come up when I pass the global state to two queries or more queries at the same time. When isolating queries everything works just fine.

After some exploration, it seems that this issue is tied to queries, rather than the new await. I have seen no issues at all when passing global state to a client side only async function, hence why I'm raising the issue in the kit repo.

Here is the documentation to the warning message that I've been getting:
Warning Docs

Update:
I found out that this has nothing to do with context/global state. As long as two different queries rely on a single piece of state, the warning will show up.

Reproduction

Link to repo

Clone the source

pnpm install
pnpm run dev

Initially, to trigger the warning you would need to click the increment button to update the 'count' state. After updating svelte from 5.37.3 to 5.38.0 and sveltekit from 2.27.0 to 2.27.1, I get the warning spam shown in the screenshot below.

Here's the code in a nutshell

<!-- Component -->
<script>
    import { returnCount, returnDouble } from "./return-count.remote";

    let count = $state(0);
</script>

<svelte:boundary>
    <div>Return Count: {await returnCount(count)}</div>
    <div>Return Double: {await returnDouble(count)}</div>
    {#snippet pending()}
        loading...
    {/snippet}
</svelte:boundary>
<button onclick={() => count++}>Increment</button>

// Remotes
import { query } from "$app/server";

export const returnCount = query("unchecked", async (count: number) => {
  // To simulate network delay
  await new Promise((resolve) => setTimeout(resolve, 300));
  return count;
});

export const returnDouble = query("unchecked", async (count: number) => {
  // To simulate network delay
  await new Promise((resolve) => setTimeout(resolve, 300));
  return count * 2;
});

gif of basic reproduction
gif of desynced state reproduction

Logs

OUTDATED:

First warning: 
[svelte] await_reactivity_lossDetected reactivity loss when reading `undefined`. This happens when state is read in an async function after an earlier `await`https://svelte.dev/e/await_reactivity_loss

Second warning: 
TracedAtError
    at get_stack (tracing.js:137:14)
    at get (runtime.js:596:17)
    at Array.map (<anonymous>)
    at effects.js:356:51
    at update_reaction (runtime.js:287:53)
    at update_effect (runtime.js:467:18)
    at flush_queued_effects (batch.js:603:4)
    at _Batch.process (batch.js:232:4)
    at flush_effects (batch.js:561:10)
    at _Batch.flush (batch.js:381:4)

Update: After updating dependencies, to see if things got fixed in other pr's I'm getting different warning messages.

First warning: 
[svelte] await_reactivity_lossDetected reactivity loss when reading `Query.#current`. This happens when state is read in an async function after an earlier `await`

Second warning: 
TracedAtError
    at get_stack (tracing.js:137:14)
    at Module.get (runtime.js:596:17)
    at Query.<anonymous> (query.svelte.js:73:12)

... and many more

System Info

System:
    OS: Windows 11 10.0.26100
    CPU: (16) x64 AMD Ryzen 7 3700X 8-Core Processor
    Memory: 19.61 GB / 31.95 GB
  Binaries:
    Node: 22.16.0 - ~\scoop\apps\nodejs-lts\current\node.EXE
    npm: 10.9.2 - ~\scoop\apps\nodejs-lts\current\npm.CMD
    pnpm: 10.13.1 - ~\scoop\shims\pnpm.EXE
    bun: 1.2.19 - ~\scoop\shims\bun.EXE
  Browsers:
    Edge: Chromium (137.0.3296.83)
  npmPackages:
    @sveltejs/adapter-auto: ^6.0.0 => 6.0.1
    @sveltejs/kit: ^2.22.0 => 2.27.0
    @sveltejs/vite-plugin-svelte: ^6.0.0 => 6.1.0
    svelte: ^5.0.0 => 5.37.3
    vite: ^7.0.4 => 7.0.6

Severity

blocking an upgrade

Additional Information

No response

[hugo-hsi-dev]

Update: This may not be tied to the context API or global state at all. All it takes for the warning to show is for two or more different (must be different) queries to consume the same piece of state and for that piece of state to change.

The most important piece of this is that it's not only a warning, but the state is actually de-synced in a lot of scenarios, namely ones that require the state to cross a component boundary.

[NickClark]

I have a very similar issue... although I still don't know what the cause is. For now, I've switched any offending code, to just using the non-await alternate API (query.loading|error|current) . I was thinking it had to do with Svelte's new async feature.

[hugo-hsi-dev]

I have a very similar issue... although I still don't know what the cause is. For now, I've switched any offending code, to just using the non-await alternate API (query.loading|error|current) . I was thinking it had to do with Svelte's new async feature.

Interesting, I'll try out using current. Does that mean you aren't using any <svelte:boundary> to handle pending and failed states?

[NickClark]

Does that mean you aren't using any <svelte:boundary> to handle pending and failed states?

For the cases that trigger this behavior I'm just replacing the boundaries with if/else.

[NickClark]

But it is disappointing that this is so buggy right now. In cases where I want a single boundary around multiple awaits (which, to me, is one of the big benefits), it seems to be hit and miss. I just haven't had the time to dig in and figure out why.

[hugo-hsi-dev]

Do you have any examples of using the non-await alternatives? I am unable to get it to work. It seems like query.current merely returns whatever is stored in client cache and doesn't actually 'call' the remote query to run server side.

I may be wrong in how query.current works, but if what I stated above is true, I will have to call the await version at some point in my application to even populate the cache.

I just tested it out real quick:

<!-- Component -->
<script>
    import { returnCount, returnDouble } from "./return-count.remote";

    let count = $state(0);
</script>

<div class="box">
    This is a minimal repro. The warning here is harmless as the async state
    from the query still updates as it's supposed to.
    <a href="/broken"
        >Click here for an example where this warning impacts the outcome of the
        query</a
    >

    <!-- These two queries will never run because they are merely searching client cache for the data -->
    <!-- Actual return value is just undefined -->
    <div>Return Count: {returnCount(count).current}</div>
    <div>Return Double: {returnDouble(count).current}</div>
    
    <button onclick={() => count++}>Increment</button>
</div>

Seems like clicking the button does nothing as well. Remote queries are the same as the ones in my original post.

[NickClark]

It appears you have to use returnCount(count).ready|loading|error or $derived. Not sure why exactly. I didn't notice this limitation because I was doing something like this:

<script>
	import { returnCount, returnDouble } from './return-count.remote';

	let count = $state(0);

	let countQuery = $derived(returnCount(count));
	let doubleQuery = $derived(returnDouble(count));
</script>

<div class="box">
	<div>Return Count: {countQuery.current}</div>
	<div>Return Double: {doubleQuery.current}</div>

	<button onclick={() => count++}>Increment</button>
</div>

[hugo-hsi-dev]

Thanks, this seems to work for the time being. Should be really easy to transition to await and svelte:boundary once things get fixed too. Appreciate the help!

[tehnrd]

All it takes for the warning to show is for two or more different (must be different) queries to consume the same piece of state and for that piece of state to change.

I can confirm this. I have a context object that stores global values across the entire app. If there are two queries in a derived that use a value from this context, there will eventually be a reactivity loss warning...but the app still seems to be reactive and work without issues.

I think it is some sort of race condition, as it is not 100% reproducible, but repeatedly changing the context value the queries depend on will cause the issue.

[dangodai]

Another trigger for this (probably currently being obscured by sveltejs/svelte#16596 for many people) that I think will be very common is loading multiple pieces of data based on a route param in a SvelteKit application. For example

<script>
    let { params } = $props()
</script>

<p>Friends: {await getUsersFriends(params.userId}</p>
<p>Enemies: {await getUsersEnemies(params.userId}</p>

there will eventually be a reactivity loss warning...but the app still seems to be reactive and work without issues.

Same, I'm not sure if there actually any reactivity loss here, or if this warning is just a false positive. But combining it with the warning from sveltejs/svelte#16483 sure fills up my console!

[hugo-hsi-dev]

...but the app still seems to be reactive and work without issues.

I haven't tested it in recent updates in the past few days, but from what I gathered from before, if the queries sit in the same component, it's as you said, reactive and no issues. However, if the queries live in different components, and are passed in through context, props, or some other mechanism, things start getting de-synced. When the state dependency changes, it might update one query without updating the other.