why context canceled?

[gonta1026]

I'm using the component to transition screens, and when I make a request with the same query, the client makes so many requests that I get a context canceld on the golang server.
This phenomenon is rare when the requestPolicy is set to network-only.
If we set requestPolicy to cache-first, which is the default, this problem does not seem to occur, but due to the nature of the application we are developing, we would like to avoid using cache as much as possible.

However, due to the nature of the application we are developing, we would like to avoid using cache as much as possible.

• Why this problem is occurring?
• Why is a large number of queries being requested just by moving from one screen to another?
• How to deal with it

sample code

// a.tsx
export default function APage() {
  const [{ data }] = useQuery({
    query: GetUserDocument,
    requestPolicy: 'network-only',
  })
  console.log('APage data', { data })
  return (
    <div style={{ width: '200px', margin: '20px auto' }}>
      <Link href={'/b'}>to B</Link>
    </div>
  )
}

// b.tsx
export default function BPage() {
  const [{ data }] = useQuery({
    query: GetUserDocument,
    requestPolicy: 'network-only',
  })
  console.log('BPage data', { data })
  return (
    <div style={{ width: '200px', margin: '20px auto' }}>
      <Link href={'/a'}>to A</Link>
    </div>
  )
}

// server log
{
  "origin": "http://localhost:3003/",
  "error": "context canceled",
  "errorVerbose": "context canceled\n(1) attached stack trace\n  -- stack trace:
  | ...
Wraps: (2) context canceled
"errCode": "INTERNAL_SERVER_ERROR"
}

screen shot

It seems that a large number of queries are issued by the client after just one screen transition.
All of these queries deal with GetUserDocument.

version

• "@urql/core": "^4.0.10"
• "next": "14.0.4",

[JoviDeCroock]

Could you make a reproduction or at least give us something to work off, your details are a bit low 😅 it could be that you are using Suspense and clearing your client every time by not catching it in a boundary located underneath your Provider.

[gonta1026]

That still doesn't show me anything

I forgot to attach the urqlClient file!💦

// urqlClient
import { Client, cacheExchange, fetchExchange } from '@urql/core'
import { devtoolsExchange } from '@urql/devtools'
import fetch from 'cross-fetch'
import { env } from '@/config'

const newUrqlClient = ({ url }: { url: string }) => {
  return new Client({
    fetch,
    url,
    exchanges: [cacheExchange, devtoolsExchange, fetchExchange],
    requestPolicy: 'network-only',
    fetchOptions: {
      headers: {
        Accept: '*/*',
        'Content-Type': 'application/json',
      },
    },
  })
}

export const urqlClient = newUrqlClient({ url: env.NEXT_PUBLIC_GRAPHQL_PROXY_ENDPOINT })

but my assumption is that _app rerenders and you keep creating a new urql client 😅

I tried to plant a log, but I couldn't find any new urql clients being new.

[gonta1026]

If you have any problems here, I would appreciate your comments.

#3465 (comment)

[gonta1026]

@JoviDeCroock

_app rerenders and you keep creating a new urql client 😅

I am aware that it is not unusual for _app.tsx to re-render, but I see this as a problem,

• A duplicate request is sent.
• context cancel occurs

I would like to know if there is a solution to the two problems. If not it may be difficult to adopt urql in the project I am participating in.

error-sample-repository

[JoviDeCroock]

Urql side

I have looked at your reproduction and honestly, I don't know why the first request goes through, this check is due to the cache-check which tries to see synchronously whether or not there is a cached item available.

• cache check
• fetchExchange safety

What this seems to signal is that the effect cleanup phase of React seems to be delayed longer than a microtick. When I change this to wait a tick i.e. setTimeout(x, 0) then it correctly cancels the request.

There are a few solutions I see here from the urql side of things

• Change the cache-check to use a cache-only policy
• Change to waiting for a tick

The issue here being that we don't know whether this react change will be long-term, Next uses an experimental version of React for everything....

CC @kitten

EDIT: after discussion with my co-maintainer we decided not to act on this, this might be related to strict-mode behaving weirdly in next,... it stands out that Next uses experimental react and us as library maintainers aren't being updated on the latest developments there.
EDIT2: in your reproduction you can prevent this issue by hoisting Layout to _app as it creates multiple versions of Layout while you do not leverage a cache meaning all of them need to fetch their own data

Your side

When I look at your reproduction I see that you are using getServerSideProps, however the cache produced by that isn't being used in your application as documented here this used next-urql but you can restore this as well with similar logic if you don't want to use that integration.

The idea here being that you fetch your data on the server but never hydrate it in your client-side cache, just wanted to highlight this in case you need to do this in the future 😅

[gonta1026]

Thanks for checking.

Change the cache-check to use a cache-only policy

The application I am developing is currently implemented without using cache as much as possible for safety reasons, so it is currently difficult to support cache-only.

Change to waiting for a tick

I don't understand the code and would appreciate it if someone could fix this...!

Your side

Thank you. I understand

---

However, in my application it is mandatory to use network only to get new information from the DB each time in a basic api request and I hope urql will solve this problem.

[gonta1026]

EDIT: after discussion with my co-maintainer we decided not to act on this, this might be related to strict-mode behaving weirdly in next,... it stands out that Next uses experimental react and us as library maintainers aren't being updated on the latest developments there.

I understand the situation...! Thank you for your consideration.

EDIT2: in your reproduction you can prevent this issue by hoisting Layout to _app as it creates multiple versions of Layout while you do not leverage a cache meaning all of them need to fetch their own data

I can confirm that this can also be solved by putting it in _app, but I am assuming that different Layout components will be used for each screen, and putting this Layout in _app is difficult in my application.

[kitten]

We'd need more information here.
There's templates for reproductions at: https://github.com/urql-graphql/urql/tree/main/examples

However, I went ahead and created two sandboxes to quickly validate this:

• app/ folder Next.js (i.e. app router): https://stackblitz.com/edit/github-qdzf6z
• pages/ folder Next.js: https://stackblitz.com/edit/github-qdzf6z-xcoiud

Those are derived from our examples, which are made for reproductions, basically.

To summarise the problem here, there's some gotchas when changing the request policy for every operation to cache-and-network. And there's even more gotchas when changing it to network-only. Notes here:

urql/packages/core/src/client.ts

Lines 153 to 156 in 73628b7

	* Hint: We don’t recommend changing this from the default `cache-first` option, unless you know what
	* you‘re doing. Setting this to `cache-and-network` is not recommend and may not lead to the behaviour
	* you expect. If you’re looking to always update your cache frequently, use `@urql/exchange-request-policy`
	* instead.

This is not a problem though! It should still work 😅
However, I think, it may lead to an issue in React, in strict mode specifically, in some cases. But that's hard for me to tell without a reproduction. 🤔

[gonta1026]

Thanks for the detailed explanation, it helped me understand better.
I would like to investigate further by looking at the documentation, sample code, and using @urql/exchange-request-policy🤗

[gonta1026]

I have a question about @urql/exchange-request-policy that caused a type error.

#3466

[gonta1026]

If you have any problems here, I would appreciate your comments.

#3465 (comment)

[gonta1026]

I'm still adjusting the code and doing some research,

• Getting Hoge with getServerSideProps.
• Get Fuga in CSR.
• context canceled 😢

but When I did urql with CSR only, without SSR, the problem did not cause the context cancel issue.

[gonta1026]

I have tried to minimize the code here to make sure it works, but on rare occasions I get an error when I make a screen transition.
I would appreciate your comments if you could look at the code and see if there are any problems.

https://github.com/gonta1026/urql-sample

[gonta1026]

For some reason, the same query appears to be requested twice on the same page and one of the requests is cancelled.