(graphcache): Getting non-stale flags for partial results

[Tigge]

Describe the bug

I'm using urql, @urql/core, @urql/exchange-graphcache and @urql/exchange-execute and I think I'm getting at least a stale state wrong. There is a small reproduction of the issue available that shows the setup, but in short:

When loading two queries (covering in part the same sections) in parallel and a partial result can be available for the slower of them the both the loading and the stale state of the slower query is set to false. This is the output I get from the reproduction (altered for clarity):

T1 {fetching: true, stale: false, data: undefined }
T2 {fetching: true, stale: false, data: undefined }

// T2 query is done loading (subFeature2 resolver returning)

T1 {fetching: false, stale: false, data: PARTIAL DATA }
T2 {fetching: false, stale: false, data: FULL DATA }

// T2 query is done loading (subFeature1 resolver returning)

T1 {fetching: false, stale: false, data: FULL DATA }
T2 {fetching: false, stale: false, data: FULL DATA }

This seems to be in contrast with the information available at https://formidable.com/open-source/urql/docs/graphcache/schema-awareness/#partial-results which suggest the stale flag should be set until the full data is available.

There has also been some discussions on this topic earlier in #2282 which also seems to align with the documentation.

I would perhaps also expect the fetching flag to be set until the first real non-partial data is present but I don't know if that is expected or not.

Reproduction

https://codesandbox.io/s/js-playground-forked-i715qc?file=/src/index.tsx

Urql version

@urql/core v3.1.1
@urql/exchange-execute v2.1.1
@urql/exchange-graphcache v5.0.8
urql v3.0.3
graphql v16.6.0

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]

Sorry for the delay, I finally had some time to look into this. To give you some context, it took me a while to get the reproduction running, since after downloading it from CodeSandbox, dependencies weren't exactly working and the JSX+TS build was failing in Parcel, so I came back to this later than I originally wanted to.

This looks to me like a regression in @urql/exchange-graphcache.

Specifically, on the following line of code, we now have a looping protection, which prevents us from reexecuting dependent operations. Basically, in your case, if we get a response from both of your queries, if both queries always remained "partial" then they'd infinitely tell each other to refetch. Of course this isn't the case, but the rule that prevents this still is being applied here:

urql/exchanges/graphcache/src/cacheExchange.ts

Line 330 in e06ba6f

!reexecutingOperations.has(res.operation.key))

However, #2831 made a change that doesn't take into account that stale still needs to be set despite the reexecution being blocked.

So, the fix is rather simple, and we'll have to set this flag regardless of whether a loop has been interrupted

[Tigge]

Thank you 💚