why context canceled? #3465

gonta1026 · 2023-12-13T10:21:09Z

gonta1026
Dec 13, 2023

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",

Answered by JoviDeCroock

Dec 19, 2023

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.

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-t…

View full answer

JoviDeCroock · 2023-12-13T10:24:05Z

JoviDeCroock
Dec 13, 2023
Maintainer

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.

8 replies

gonta1026 Dec 13, 2023
Author

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 Dec 18, 2023
Author

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

#3465 (comment)

gonta1026 Dec 19, 2023
Author

@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 Dec 19, 2023
Maintainer

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.

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 😅

Answer selected by gonta1026

gonta1026 Dec 20, 2023
Author

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 Dec 20, 2023
Author

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 · 2023-12-13T14:09:30Z

kitten
Dec 13, 2023
Maintainer

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. 🤔

3 replies

gonta1026 Dec 13, 2023
Author

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 Dec 15, 2023
Author

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

#3466

gonta1026 Dec 18, 2023
Author

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

#3465 (comment)

gonta1026 · 2023-12-15T10:00:37Z

gonta1026
Dec 15, 2023
Author

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.

0 replies

gonta1026 · 2023-12-18T09:07:20Z

gonta1026
Dec 18, 2023
Author

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

1 reply

gonta1026 Dec 18, 2023
Author

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

why context canceled? #3465

Uh oh!

gonta1026 Dec 13, 2023

sample code

screen shot

version

Urql side

Replies: 4 comments · 12 replies

Uh oh!

Uh oh!

JoviDeCroock Dec 13, 2023 Maintainer

Uh oh!

gonta1026 Dec 13, 2023 Author

Uh oh!

gonta1026 Dec 18, 2023 Author

Uh oh!

gonta1026 Dec 19, 2023 Author

Uh oh!

Uh oh!

JoviDeCroock Dec 19, 2023 Maintainer

Urql side

Your side

Uh oh!

gonta1026 Dec 20, 2023 Author

Uh oh!

gonta1026 Dec 20, 2023 Author

Uh oh!

kitten Dec 13, 2023 Maintainer

Uh oh!

gonta1026 Dec 13, 2023 Author

Uh oh!

gonta1026 Dec 15, 2023 Author

Uh oh!

gonta1026 Dec 18, 2023 Author

Uh oh!

Uh oh!

gonta1026 Dec 15, 2023 Author

Uh oh!

Uh oh!

gonta1026 Dec 18, 2023 Author

Uh oh!

gonta1026 Dec 18, 2023 Author

gonta1026
Dec 13, 2023

Replies: 4 comments 12 replies

JoviDeCroock
Dec 13, 2023
Maintainer

gonta1026 Dec 13, 2023
Author

gonta1026 Dec 18, 2023
Author

gonta1026 Dec 19, 2023
Author

JoviDeCroock Dec 19, 2023
Maintainer

gonta1026 Dec 20, 2023
Author

gonta1026 Dec 20, 2023
Author

kitten
Dec 13, 2023
Maintainer

gonta1026 Dec 13, 2023
Author

gonta1026 Dec 15, 2023
Author

gonta1026 Dec 18, 2023
Author

gonta1026
Dec 15, 2023
Author

gonta1026
Dec 18, 2023
Author

gonta1026 Dec 18, 2023
Author