A possible breaking change after graphcache 4 > 6.

[frederikhors]

Hi urql team!

Thanks again for your work on this amazing project! ❤️

I'm opening this question because in the transition from graphcache version 4 to version 6 I noticed a breaking change which unfortunately is not fixable even using request-policy-exchange (from the advice @kitten gave me).

Steps to reproduce (using request-policy-exchange)

1. Start the backend visiting: https://codesandbox.io/p/sandbox/h1pcl

2. Open the frontend reproduction: https://codesandbox.io/p/sandbox/n9zgfw

3. Go to the "Todos list" page and wait for todos list to be rendered

4. Now the cache is fullfilled with todos

5. Try to delete some todos, or click the button "Add more random todos"

6. Click on the "Reload" button

7. As you can see the (old) list is immediately loaded (from the cache) > a call is pending > but the stale flag is false and the data is not updated.

This is a big problem for our applications

Almost all of the clients of our customers are browsers on low hardware and with little RAM. Those browsers are closed by the operating system and are restarted when you return to use them. As you can imagine if the data is not reloaded when the page restarts it is a serious problem.

I also tried using shouldUpgrade, but the data doesn't get updated.

I know I opened a similar issue before this one, but only now have I tried everything I could to curb the problem, without success.

I'm the last person on earth who wants to annoy: but this is a real problem.

[probablykabari]

Are you still having this issue? I don't quite follow the codesandbox given the commented out parts (assuming this is WiP).

[frederikhors]

Yeah: I still have this issue.

This is not a WIP. This is a small reproduction of the issue.

This is the gif from this issue:

[kitten]

Sorry, but I won't have a lot of time for this until approximately the end of the month.
I wanted to summarise some of the problems, but I actually realised that a prior assumption presented here wasn't correct which caused an incorrect fix.

As I mentioned in a prior issue, there was a cancellation bug that was causing network requests to not be aborted in some cases. However, I believe, at the time you said that it still caused duplicate requests.

I have a better workaround that will allow any operation kind to pass through, which likely will make this more intuitive. And what didn't add up at the time was that the teardown that the offlineExchange issues didn't stop the duplicate request for you.
However, I believe there may be an explanation for that. Testing this in Chromium instead and looking at the stack trace, I don't recognise the first request here as issued by offlineExchange:

The second request is being issued as I'd expect:

If I had to guess, SvelteKit is messing with the fetch function and as long as that's not disabled or gotten rid of, we won't see correct behaviour here even with the fix. I don't really know this part of SvelteKit, so I don't know how to disable this, but I think I've got a fix I can test against this and the past reproductions once we do know.

Anyway, all I can tell is that export const ssr = false doesn't seem to disable whatever this is.

Either this fetch proxy isn't letting the request be cancelled, or it's repeating a past request. Maybe both

[frederikhors]

As I mentioned in a prior issue, there was a cancellation bug that was causing network requests to not be aborted in some cases. However, I believe, at the time you said that it still caused duplicate requests.

Yeah, all happened here.

SvelteKit is messing with the fetch function and as long as that's not disabled or gotten rid of, we won't see correct behaviour here even with the fix.

Are you really sure is a Kit fault? I can open an issue on Kit's repo, but how can we be 100% sure?

export const ssr = false

It worked on my projects, plus in my reproduction I'm using the static adapter. I'm not using SSR at all.

I think I've got a fix I can test against this and the past reproductions once we do know.

I can help you testing this, I'm here for you.

I updated my reprodocution dependencies and I tried with graphcache code from https://github.com/urql-graphql/urql/actions/runs/5514888811. Still the double call on reload.

https://codesandbox.io/p/sandbox/issue-urql-6-reload-on-start-230719-1833-9xn6p4.

Is there a new graphcache build I can try?

[kitten]

Here you can see a demo with Vue + React instead of SvelteKit: https://stackblitz.com/edit/github-7wamlu

The setup should, if I'm not mistaken, be 100% equivalent. I haven't edited any of the queries of course. The duplicate request issue is entirely missing in this setup.

I of course haven't bothere to copy over your testing API and queries, but since they don't do anything special, I don't think that's necessary. This basically demonstrates that the issue — if it even is a real issue, since I haven't traced whether SvelteKit's fetch proxy simply fails to be cancelled or is indeed a duplicate — doesn't occur in a different non-SvelteKit setup.

The installed version of Graphcache is after the PR has been merged, i.e. from this commit: 7ddccc1

[frederikhors]

if it even is a real issue

I don't understand. Are the duplicate calls an issue for you or not? :LOL:

The duplicate request issue is entirely missing in this setup.

I can see the double query in your new reproduction too!:

But the first one is canceled.

Do you see the same?

I'm using Chrome 114.

[frederikhors]

WOWOWOWOWWOWOWOWOWOWOWWOWOW!

IT WORKS!!!!!!! I tried it on Stackblitz and it worked!

I'll never try something on codesandbox!

I cannot believe this!

https://stackblitz.com/edit/sveltejs-kit-template-default-y5hteh

[frederikhors]

@kitten, just for your information.

After yesterday's excitement about how 6.1.5-canary works on Stackblitz today I tried 6.1.5-canary on my real project and unfortunately ran into problems.

I can't even explain them: I refresh the page and on each reload there are different queries that don't make sense, many times also duplicated. Many components use cache-first internally but with each reload the result changes: sometimes they are loaded and sometimes they are not. In theory since I'm NOT using the requestPolicyExchange and I'm using cache-first everywhere this shouldn't be happening yet it does.

I'm waiting for a definitive version of 6.1.5 to try again because maybe the problem is the incompatibility of the two @urql/core, but I must say that I'm very disconsolate right now.