Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix(client): eager unblocking of in-flight operations #3573

Merged
merged 11 commits into from
Apr 24, 2024

Conversation

JoviDeCroock
Copy link
Collaborator

@JoviDeCroock JoviDeCroock commented Apr 24, 2024

Resolves #3565

Summary

In the initial issue we were faced with the following problem, imagine a query that returns a list with values [Todo:1, Todo:2] we use this list to return components that in turn has its own query to fetch the details of this Todo. Both this list and the details have a shared parent field let's name it Query.author, this is important for graph-cache to re-dispatch operations.

This diagram of this looks like the following

Operation List
Completed Operation List
Operation Todo:1
Operation Todo:2
Completed Operation Todo:1
Operation Todo:2
Completed Operation Todo:2
Completed Operation Todo:2

Notice that we re-dispatch Todo:2 even though it is already in-flight, this is problematic as in the cache it has not resolved to a response yet and hence we send off multiple network requests. This issue becomes more and more apparent given more queries being in-flight. The lines causing this issue can be found here since there is no operation queued we will always remove the operation from our in-flight operations.

The solution here is to change this logic to only remove dispatched on a queued operation that either is already in dispatched or is network-only.

I did notice that #3564 already makes this issue less severe due to dispatching less operations from graphcache.

The above fix however re-introduces the issue we faced in #3254 this due to our optimistic mutation re-triggering the operation and resulting in stale and then our real data re-triggering the query but it already having been dispatched. This because we have similar logic in the onPush part of our operation. When it's stale we'll check the queue whether there is an operation in there, however there won't be as we are dealing with an optimistic mutation re-trigger, to fix this I added a check whether the stale result has a next payload coming, if not it gets deleted form dispatched either way.

I think the above stale flag fix is the root cause that needed to be addressed in #3254 but I am not a 100% sure as I got a bit overloaded while leveraging console.log in all of these reproductions 😅

Copy link

changeset-bot bot commented Apr 24, 2024

🦋 Changeset detected

Latest commit: b82e184

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package
Name Type
@urql/core Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

@JoviDeCroock JoviDeCroock changed the title present fix for subsequent operations fix(client): eager unblocking of in-flight operations Apr 24, 2024
@JoviDeCroock JoviDeCroock force-pushed the fix-subsequent-operations branch 3 times, most recently from 4e88864 to fec9546 Compare April 24, 2024 08:21
@JoviDeCroock JoviDeCroock marked this pull request as ready for review April 24, 2024 08:26
Co-authored-by: Phil Pluckthun <phil@kitten.sh>
@JoviDeCroock JoviDeCroock merged commit 0f3c5c0 into main Apr 24, 2024
7 checks passed
@JoviDeCroock JoviDeCroock deleted the fix-subsequent-operations branch April 24, 2024 11:28
@github-actions github-actions bot mentioned this pull request Apr 22, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Multiple requests when using react suspense
2 participants