Queries or mutations hang when using 'cache-first' or 'cache-only' request policies

[tmaxmax]

After a while of using this client, queries and mutations started to hang indefinitely if using request policies that try retrieving from the cache first. What is surprising is that this didn't happen since the beginning and it happens when deployed and on local m Linux machine, but not on my other Windows computer. As a temporary solution, I am using cache-and-network for queries and network-only for mutations, at the expense of longer loading times and wasteful requests.

urql version & exchanges:

"dependencies": {
  "@urql/devtools": "^2.0.3",
  "@urql/exchange-retry": "^0.2.1",
  "@urql/svelte": "^1.2.2",
  "graphql": "^15.5.0",
  "subscriptions-transport-ws": "^0.9.18"
}

const exchanges = [
  dedupExchange,
  cacheExchange,
  errorExchange({
    onError(error, operation) {
      // side-effect-free custom code, logging only
    },
  }),
  retryExchange({
    retryIf(error) {
      // side-effect-free code, retries on networkError and some other custom scenarios
    },
  }),
  fetchExchange,
  subscriptionExchange({
    forwardSubscription(operation) {
      return subscriptionClient.request(operation)
    },
  }),
]

if (import.meta.env.DEV) {
  exchanges.push(devtoolsExchange)
}

export default new Client({
  url, // the Hasura endpoint
  fetchOptions: getHeaders, // function that returns a header object with an authorization entry
  exchanges,
})

Steps to reproduce

It's not clear to me how I could reproduce this. I'm having this problem in a Svelte + Hasura application, which in development is ran using a devcontainer configured with docker-compose (link, if useful), and is deployed to Vercel in production. I've noticed that it doesn't happen when running the development environment on Windows.
I am also using rxjs in my codebase, so I have some helpers that wrap urql's queries and mutations' promises into observables: (code here). I stepped through my code with both Chrome's and Firefox's debuggers and it didn't result that my helpers were a problem, but knowing this implementation detail maybe could help.
As a sidenote, this doesn't seem to happen when using the Svelte-specific helpers (query, mutation, operationStore). You can find here the queries used in my project - maybe there's something about them that breaks the client's caching system.
Finally, if you have any idea on how I could isolate this problem I will certainly use it to improve this issue.

Expected behavior

Fetch the response successfully, according to the given policy.

Actual behavior

Hangs indefinetly after calling either the query or mutation methods (subscriptions work).

I hope it's the right place to ask this, as I believe there's a chance this isn't related to the urql client, and I definitely could use some help with it - I'm at a complete loss and without any idea on how to fix this. Thanks for your help and attention, and for the extensive effort that went into creating this library!

[brentvatne]

we encountered this in eas-cli as well, except in our case rather than hanging the node process would exit immediately with status code 0. we didn't tease out a minimal reproducible example from this unfortunately, but i'm happy to walk a maintainer through reproducible it within our repository if needed. we are locking our urql version to 2.0.0 for now to avoid this issue.

[kitten]

@tmaxmax @brentvatne Let's try to narrow this down first ✌️ We suspect this is only happening in @urql/core@^2.1.0 so if you create a Yarn resolution for "@urql/core": "2.0.0" is the issue indeed gone? Also, do you happen to be able to add some debugExchange output here? That may give us a hint. The issue we're having is that we're not aware of any situations that could lead to no results at all 🤔 but then again, we may be missing something obvious

Edit: actually, it may look like we have some kind of weird condition in which toPromise simply fails. I'm rather confused by this but we're looking into this

[brentvatne]

i wasn't super familiar with this code before i started to investigate this issue, so i'm not sure if this is the right thing - what i did was add some logging with graphqlClient.subscribeToDebugTarget. the output wasn't super useful though: https://gist.github.com/brentvatne/78009849d97b73a7be7086f12370960f (ignore the surrounding unrelated logs). apple developer portal is currently down for maintenance and this was necessary for me to repro in our project 😂

toPromise is also what i stumbled on - i stepped through execution until the process exited and this was the last frame:

i was also rather confused by this

[kitten]

I'm still very confused myself, but I'm hitting myself for not finding a nicer implementation for our new replay/single-source behaviour in client.executeRequestOperation 😅 It's not the implementation that's wrong to be fair, but that's what seems to be causing the issues. I found a fix though: #1634

[kitten]

@tmaxmax @brentvatne This should be fixed in @urql/core@2.1.2