Test demonstrating a bug in flattenAsyncIterable #3709
Closed
Conversation
This file contains hidden or 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
# Conflicts: # src/execution/execute.ts # src/validation/index.d.ts # src/validation/index.ts
…phql#2843) # Conflicts: # src/execution/execute.ts
* fix(race): concurrent next calls * refactor test * use invariant * disable eslint error * fix
If next() is called in parallel, you can have multiple next()s both waiting on a higher-level iterator, and the second one will move on to the next sub-iterator rather than diving in to the iterator returned by the first one.
|
Hi @glasser, I'm @github-actions bot happy to help you with this PR 👋 Supported commandsPlease post this commands in separate comments and only one per comment:
|
robrichard
force-pushed
the
defer-stream
branch
from
55ac8df to
172c853
Compare
glasser
added a commit
to glasser/graphql-js
that referenced
this pull request
Aug 19, 2022
Use distinct types for "the only result of a single-payload execution", "the first payload of a multi-payload execution", and "subsequent payloads of a multi-payload execution", since the data structures are different. Wrap the first payload and the subsequent payloads in an `AsyncExecutionResultStream`. You can now differentiate this from the single-result case by checking `'initialResult' in result` rather than `isAsyncIterable`; TS inference works better this way. flattenAsyncIterable now works on iterables of precisely one nesting level, and it fixes graphql#3709.
glasser
added a commit
to glasser/graphql-js
that referenced
this pull request
Aug 19, 2022
Use distinct types for "the only result of a single-payload execution", "the first payload of a multi-payload execution", and "subsequent payloads of a multi-payload execution", since the data structures are different. Wrap the first payload and the subsequent payloads in an `AsyncExecutionResultStream`. You can now differentiate this from the single-result case by checking `'initialResult' in result` rather than `isAsyncIterable`; TS inference works better this way. flattenAsyncIterable now works on iterables of precisely one nesting level, and it fixes graphql#3709.
glasser
added a commit
to glasser/graphql-js
that referenced
this pull request
Aug 19, 2022
Use distinct types for "the only result of a single-payload execution", "the first payload of a multi-payload execution", and "subsequent payloads of a multi-payload execution", since the data structures are different. Wrap the first payload and the subsequent payloads in an `AsyncExecutionResultStream`. You can now differentiate this from the single-result case by checking `'initialResult' in result` rather than `isAsyncIterable`; TS inference works better this way. flattenAsyncIterable now works on iterables of precisely one nesting level, and it fixes graphql#3709.
glasser
added a commit
to glasser/graphql-js
that referenced
this pull request
Aug 19, 2022
Use distinct types for "the only result of a single-payload execution", "the first payload of a multi-payload execution", and "subsequent payloads of a multi-payload execution", since the data structures are different. Wrap the first payload and the subsequent payloads in an `AsyncExecutionResultStream`. You can now differentiate this from the single-result case by checking `'initialResult' in result` rather than `isAsyncIterable`; TS inference works better this way. flattenAsyncIterable now works on iterables of precisely one nesting level, and it fixes graphql#3709.
robrichard
force-pushed
the
defer-stream
branch
from
172c853 to
feb203a
Compare
glasser
added a commit
to glasser/graphql-js
that referenced
this pull request
Aug 19, 2022
Fixes the bug demonstrated in graphql#3709 (which has already been incorporated into the defer-stream branch). This fix is extracted from graphql#3703, which also updates the typing and API around execute. This particular change doesn't affect the API (other than making the `subscribe` return type more honest, as its returned generator could yield AsyncExecutionResult before this change as well).
glasser
added a commit
to glasser/graphql-js
that referenced
this pull request
Aug 19, 2022
Fixes the bug demonstrated in graphql#3709 (which has already been incorporated into the defer-stream branch). This fix is extracted from graphql#3703, which also updates the typing and API around execute. This particular change doesn't affect the API, other than making the `subscribe` return type more honest, as its returned generator could yield AsyncExecutionResult before this change as well. (The reason the previous version built is because every ExecutionResult is actually an AsyncExecutionResult; fixing that fact is part of what graphql#3703 does.)
glasser
added a commit
to glasser/graphql-js
that referenced
this pull request
Aug 19, 2022
Fixes the bug demonstrated in graphql#3709 (which has already been incorporated into the defer-stream branch). This fix is extracted from graphql#3703, which also updates the typing and API around execute. This particular change doesn't affect the API, other than making the `subscribe` return type more honest, as its returned generator could yield AsyncExecutionResult before this change as well. (The reason the previous version built is because every ExecutionResult is actually an AsyncExecutionResult; fixing that fact is part of what graphql#3703 does.)
robrichard
pushed a commit
that referenced
this pull request
Aug 20, 2022
Fixes the bug demonstrated in #3709 (which has already been incorporated into the defer-stream branch). This fix is extracted from #3703, which also updates the typing and API around execute. This particular change doesn't affect the API, other than making the `subscribe` return type more honest, as its returned generator could yield AsyncExecutionResult before this change as well. (The reason the previous version built is because every ExecutionResult is actually an AsyncExecutionResult; fixing that fact is part of what #3703 does.)
robrichard
pushed a commit
that referenced
this pull request
Aug 23, 2022
Fixes the bug demonstrated in #3709 (which has already been incorporated into the defer-stream branch). This fix is extracted from #3703, which also updates the typing and API around execute. This particular change doesn't affect the API, other than making the `subscribe` return type more honest, as its returned generator could yield AsyncExecutionResult before this change as well. (The reason the previous version built is because every ExecutionResult is actually an AsyncExecutionResult; fixing that fact is part of what #3703 does.)
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.
If next() is called in parallel, you can have multiple next()s both
waiting on a higher-level iterator, and the second one will move on to
the next sub-iterator rather than diving in to the iterator returned by
the first one.