network-only + React 19 creates phantom teardown requests

[giacomocerquone]

Describe the bug

Hello there. Thanks for all the work you put in this project!

This issue is most probably related to #3764 but it's different since the behavior I'm experiencing (both in dev and in production) appears in the network tab where some requests show as canceled (so not only a react warning).

I've created a repro here: https://github.com/giacomocerquone/urql-teardown-react19-router-bug where you also have a video showing both the urql's devtools and the network tab.

The TLDR of the problem is the following:

1. react-router 7 in declarative mode (so the most basic possible way of moving between pages)
2. React 19 and urql 4.2.2
3. I have two pages containing two useQuery sharing the same query with a network-only policy
4. When I navigate from Page1 to Page2, I see a first request being torn down and immediately after a new request which will actually return successfully.

Reproduction

https://github.com/giacomocerquone/urql-teardown-react19-router-bug

Urql version

Latest 4.2.2

Validations

• I can confirm that this is a bug report, and not a feature request, RFC, question, or discussion, for which GitHub Discussions should be used
• Read the docs.
• Follow our Code of Conduct

[kitten]

Admittedly, I don't really understand what the unexpected behaviour is here, especially since you're referring to the operation which from the perspective of the bindings and UI are an implementation detail 😅

Then the second problem is, please don't use network-only in UI code or React. As a base network policy for UI code this is unsupported and leads to unexpected behaviour (unrelated to what you're seeing here)
Basically, it bypasses the cache which means on every render you'll see a request. Because of React Concurrent, this may happen in unintuitive ways too.

The next part is, when you go from one screen to another, one query unmounts, the other mounts, which means, if there's no cache and depending on whether there's a gap between the two, the teardown is expected since it signifies that the "observable" period of receiving results is done, i.e. all it does is say "no consumers are using this query anymore"

It also is relevant for caching, however, if you were to set network-only, this doesn't make sense for bindings, since network-only basically bypasses the cache and hence disables reactivity.

Lastly, without a cache, not only do you lose reactivity, but it basically is an anti-pattern in React specifically. While there is a special Suspense mode cache layer, and a deduplication layer (an active operation state on the client), without a cache, the client breaks the rules of react (in relation to its update model)

[giacomocerquone]

The unexpected behavior, from my point of view, is the additional request being torn down.

Then you explained why what I consider to be an unexpected behavior is actually obvious to happen due to some technical details internal to the lib unspecified anywhere in the docs (thanks for the very thorough explanation).

In the end, it also makes sense that bypassing entirely the cache, at each render urql will just fire a new request and this may conflict with very fast rerenders that would cause other requests to be canceled with only one last standing I suppose.

I see it as unexpected also because it doesn't happen with react 18, or react-router 6 or react-query and it's due to implementation details in both react and urql.

[kitten]

What basically works is either:

• using suspense consistently without a cacheExchange (dangerous, but less so, and will refetch on every update, so be careful with that)
• using cache-and-network with a cache exchange (can still cause issues, but is more expected and less prone to refetches)

Basically, unlike some other fetching implementations, @urql/core is very reactive and stateless, meaning, it's completely decoupled from its cache implementation. This can however break the rules of react, in regards to Suspense and Concurrent, which aren't well documented.

Basically, when you're using React, you shouldn't bypass the cache and have an effective cache, which guarantees that with the same conditions a re-render won't kick off a state change.

With Suspense, this rule is a little more relaxed and we have a secondary cache, but other rules apply. However, the re-fetching behaviour here is typically more expected and accounted for by React.

[giacomocerquone]

@kitten Just so we're all on the same page here, quoting the other issue I linked:

The error only happens when using network-only, and when the two query invocation has the same query name. (There's an extra page on next's example that test it). On nextjs, it happens regardless using network-only or not

You never actually mentioned all this in that thread 🤔 is it a different situation or what you wrote here also applies in that issue the other user is experiencing? I guess the latter since the user said is using network-only