[2.65.0] Broken reactivity with remote query and `#each` block

[henrykrinkle01]

Describe the bug

After upgrading Kit to 2.65.0 and beyond my app is broken. Remote queries don't rerun when their parameter gets updated. It was working fine in 2.63.1. I believe PR #15991 is the cause for this.

Reproduction

https://stackblitz.com/edit/sveltejs-kit-template-default-bgzakgon?file=src%2Froutes%2Fdata.remote.ts,src%2Froutes%2F%2Bpage.svelte,src%2Froutes%2Forder-card.svelte,src%2Froutes%2Fshared.svelte.ts,src%2Froutes%2Fitem.svelte

Logs

System Info

svelte@5.56.4
kit@2.69.1

Severity

blocking an upgrade

Additional Information

No response

[elliott-with-the-longest-name-on-github]

I'm trying to understand your reproduction. What is the context you're using for?

[henrykrinkle01]

I use the context to pass the query instance together with its parameter down to components. The parameter comes from the route params combined with URL searchParams. However, to keep it simple I just use a $state in the reproduction.

Alternatively, I can put the params into a context, retrieve that in child components and call getQuery(params). That was I was using before #16211. This approach produces the same bug. Updated the reproduction to include this alternative path.

Passing the query result directly as a prop doesn't produce the bug.

[elliott-with-the-longest-name-on-github]

My best guess right now is that this is a bug with async interacting with context... have you tried not using context and using page.params and page.url.searchParams?, or putting the derived result of those into context and then calling the remote function where you need it? (Not saying this isn't a bug, just looking for a workaround in the meantime.)

[henrykrinkle01]

or putting the derived result of those into context and then calling the remote function where you need it

Yes, that was I was using. The reproduction also includes that path if you want to try.

Using page.params and page.url.searchParams means I have to parse them again and again in a couple dozens of component, which is undesirable. I'd like to parse them once and put the result into a context, or put the query with the parsed params into the context.

I think it's somehow related to remote query cache and garbage collector. Because if I call the query, refresh the page and call the query again, the bug shows up. However, if I call the query, doesn't matter bugged or not, refresh the page, wait for a while then call the query again, it returns the correct result.

[elliott-with-the-longest-name-on-github]

I'm doubtful that it has anything to do with the garbage collector because as long as anything in your code is holding a reference to the query, it can't get cleaned up, and since your context is definitely holding onto it... it must still be there. Also the cache isn't preserved cross-hard-navigation (it's just a Map). So I'm not sure what's going on here yet.

[henrykrinkle01]

Or maybe the browser cache is involved somehow? I've noticed another issue where a list is updated and refreshed, then a navigation happens, then pressing the back button will show the old values instead. Trying to reproduce.

[henrykrinkle01]

On the reproduction, I added a simple count variable on the server to track the number of query calls. Can be observed in the network tab too.
In 2.64.0, when you click an order selection button, the query is called exactly once.
In 2.65.0, when doing the same, the query is called 3 times. Clicking the other button will call the query another 5 times.
So they don't reuse the query cache?

[Nic-Polumeyv]

Instrumented the cache and ran the repro against main (08cfba0, svelte 5.56.4), with 2.64.0 as a control. 2.64.0 makes 1 request per param change. Main makes 6, deterministically: 3 for the new arg, 3 refetching the one you just left. One "order #1" click:

deref     getOrder {id:0} -> 0    pin_in_effect cleanup on effect rerun
new Query getOrder {id:1}
RUN       getOrder {id:1}
EVICT     getOrder {id:0}         still rendered
RUN       getOrder {id:1}         same instance
new Query getOrder {id:0}         recreated, refetches 3x
RUN       getOrder {id:1}         same instance

Two findings:

1. The outgoing entry is evicted while still rendered. Its last ref at idle is the pin_in_effect pin (the proxies are long GC'd; forcing gc() makes it deterministic), and the $effect.pre cleanup releases it on rerun, before the async transition commits. Later evaluations in the same update recreate and refetch it. Same eviction happens on 2.64.0, harmless there.

2. #promise ??= #run() doesn't memoize. All six RUNs come via the #then derived, refresh()/reset() never called, one instance per key, so a single instance fetches 3x. Doesn't happen on 2.64.0 with the same svelte and the same #then code, so the extra evaluations trace to fix: dedupe remote data #15991.

The stale UI is the race between the two: when the eviction lands mid-flight, the response settles an instance the view isn't subscribed to (query_map isn't reactive) and it freezes at the old value. 1 in 6 runs on the click/reload/click sequence, silent. Late responses get stashed in query_responses and seed the next instance, which is why waiting heals it, and prop-passing keeps the proxy referenced, which is why that path works.