-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
RFC: deduplicated incremental delivery #1052
Closed
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
✅ Deploy Preview for graphql-spec-draft ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
yaacovCR
force-pushed
the
deduplicate3
branch
from
November 6, 2023 14:29
04d0164
to
9d2f796
Compare
yaacovCR
force-pushed
the
deduplicate3
branch
6 times, most recently
from
November 7, 2023 09:59
4e836eb
to
b5aa295
Compare
yaacovCR
changed the title
Deduplicated incremental delivery (without mutation of global state or subprocedures)
RFC: deduplicated incremental delivery
Nov 7, 2023
yaacovCR
force-pushed
the
deduplicate3
branch
5 times, most recently
from
November 9, 2023 12:16
fec902b
to
9e13d28
Compare
extracted out #1054 from this PR to simply a bit |
yaacovCR
force-pushed
the
deduplicate3
branch
from
November 18, 2023 20:58
9e13d28
to
d9af65d
Compare
yaacovCR
force-pushed
the
deduplicate3
branch
7 times, most recently
from
December 4, 2023 12:37
0a801eb
to
0f7b66f
Compare
…payload stream The update stream suppresses future completion that should not lead to a response, i.e. now all incremental entries for a given fragment have been completed. The payload stream does the response formatting. NOTE: I think it is possible that we can move payload response formatting out of the execution section entirely, and into the Response section.
we start at the number of deferred fragments and then go down
have to update the pendingFutures set when completing a fragment
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Iterating on #1034 and #1026, removed mutation of internal state, event stream management, and the need for subprocedures.
YieldSubsequentPayloads now is passed the entirety of the "state," pending futures, etc, monitors for any changes to pending futures, rebuilds a new "state" representation based on any changes, yields a single result as necessary, and then recursively calls itself to yield remaining results.
[The diff to main might be helpful, but this is built on top of the amazing #742 and so the diff from that branch could be more useful.]