execute: integrate subscriptions and refactor pipeline - #3644
Closed
yaacovCR wants to merge 13 commits into
Closed
Conversation
✅ Deploy Preview for compassionate-pike-271cb3 ready!
To edit notification comments on pull requests, go to your Netlify site settings. |
|
Hi @yaacovCR, 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:
|
n1ru4l
approved these changes
Jun 14, 2022
yaacovCR
force-pushed
the
make-execute-happen
branch
4 times, most recently
from
June 14, 2022 10:50
ce28d68 to
dc3b18d
Compare
yaacovCR
added
the
PR: breaking change 💥
yaacovCR
force-pushed
the
make-execute-happen
branch
8 times, most recently
from
June 21, 2022 20:36
393bdfc to
eaf786d
Compare
yaacovCR
force-pushed
the
make-execute-happen
branch
4 times, most recently
from
June 22, 2022 19:31
cbd99b5 to
6946681
Compare
yaacovCR
force-pushed
the
make-execute-happen
branch
from
June 24, 2022 08:25
a198622 to
f18583f
Compare
The `execute`/`executeImpl` and `createSourceEventStream`/`createSourceEventStreamImpl` functions follow the same basic pattern of building the contet and using it to run a function. This PR extracts that pattern into a separate function. For good measure, the same pattern in applied to the soon-to-be-deprecated `subscribe` function. Hheavier refactoring is on the way from @IvanGoncharov (see graphql#3639 (review)), but in the meantime, this consolidates the common pattern without any breaking changes.
...to executeSubscriptionRootField => because that's what it does!
...because that's what it does! The execution of an operation returns a map of data/errors, not just the data.
`execute` no longer runs the query algorithm for subscription operations. Rather, subscription operations are performed, as per the spec. `subscribe` is deprecated.
to replace the old exported functionality from execute
Contributor
Author
|
The new |
Contributor
Author
|
Ah => I forgot to mention that I have also snuck in here a new argument to allow total customization of the executor used by EXECUTE_SUBSCRIPTION_EVENT. As well as a default executor: export const defaultSubscriptionEventExecutor = (
exeInfo: ExecutionInfo,
payload: unknown,
): PromiseOrValue<ExecutionResult> =>
executeQuery({
...exeInfo,
rootValue: payload,
});This workflow allows the |
yaacovCR
changed the title
Contributor
Author
|
Closing this for now in favor of plan in #4210 |
yaacovCR
added a commit
that referenced
this pull request
Oct 1, 2024
to safely export buildExecutionContext() as validateExecutionArgs() motivation: this will allow us to: 1. export `executeOperation()` and `executeSubscription()` for those who would like to use directly. 2. add a `perEventExecutor` option to `ExecutionArgs` that allows one to pass a custom context for execution of each execution event, with the opportunity to clean up the context on return, a la #2485 and #3071, addressing #894, which would not require re-coercion of variables. The signature of the `perEventExecutor` option would be: ```ts type SubscriptionEventExecutor = ( validatedExecutionArgs: ValidatedExecutionArgs): PromiseOrValue<ExecutionResult> ``` rather than: ```ts type SubscriptionEventExecutor = ( executionArgs: ExecutionArgs): PromiseOrValue<ExecutionResult> ``` This might be a first step to integrating `subscribe()` completely into `execute()` (see: #3644) but is also a reasonable stopping place.
erikwrede
pushed a commit
to erikwrede/graphql-js
that referenced
this pull request
Oct 17, 2024
to safely export buildExecutionContext() as validateExecutionArgs() motivation: this will allow us to: 1. export `executeOperation()` and `executeSubscription()` for those who would like to use directly. 2. add a `perEventExecutor` option to `ExecutionArgs` that allows one to pass a custom context for execution of each execution event, with the opportunity to clean up the context on return, a la #2485 and #3071, addressing #894, which would not require re-coercion of variables. The signature of the `perEventExecutor` option would be: ```ts type SubscriptionEventExecutor = ( validatedExecutionArgs: ValidatedExecutionArgs): PromiseOrValue<ExecutionResult> ``` rather than: ```ts type SubscriptionEventExecutor = ( executionArgs: ExecutionArgs): PromiseOrValue<ExecutionResult> ``` This might be a first step to integrating `subscribe()` completely into `execute()` (see: graphql/graphql-js#3644) but is also a reasonable stopping place.
yaacovCR
pushed a commit
to yaacovCR/graphql-js
that referenced
this pull request
Dec 13, 2025
to safely export buildExecutionContext() as validateExecutionArgs() motivation: this will allow us to: 1. export `executeOperation()` and `executeSubscription()` for those who would like to use directly. 2. add a `perEventExecutor` option to `ExecutionArgs` that allows one to pass a custom context for execution of each execution event, with the opportunity to clean up the context on return, a la graphql#2485 and graphql#3071, addressing graphql#894, which would not require re-coercion of variables. The signature of the `perEventExecutor` option would be: ```ts type SubscriptionEventExecutor = ( validatedExecutionArgs: ValidatedExecutionArgs): PromiseOrValue<ExecutionResult> ``` rather than: ```ts type SubscriptionEventExecutor = ( executionArgs: ExecutionArgs): PromiseOrValue<ExecutionResult> ``` This might be a first step to integrating `subscribe()` completely into `execute()` (see: graphql#3644) but is also a reasonable stopping place.
yaacovCR
pushed a commit
to yaacovCR/graphql-js
that referenced
this pull request
Dec 16, 2025
to safely export buildExecutionContext() as validateExecutionArgs() motivation: this will allow us to: 1. export `executeOperation()` and `executeSubscription()` for those who would like to use directly. 2. add a `perEventExecutor` option to `ExecutionArgs` that allows one to pass a custom context for execution of each execution event, with the opportunity to clean up the context on return, a la graphql#2485 and graphql#3071, addressing graphql#894, which would not require re-coercion of variables. The signature of the `perEventExecutor` option would be: ```ts type SubscriptionEventExecutor = ( validatedExecutionArgs: ValidatedExecutionArgs): PromiseOrValue<ExecutionResult> ``` rather than: ```ts type SubscriptionEventExecutor = ( executionArgs: ExecutionArgs): PromiseOrValue<ExecutionResult> ``` This might be a first step to integrating `subscribe()` completely into `execute()` (see: graphql#3644) but is also a reasonable stopping place.
yaacovCR
pushed a commit
to yaacovCR/graphql-js
that referenced
this pull request
Dec 16, 2025
to safely export buildExecutionContext() as validateExecutionArgs() motivation: this will allow us to: 1. export `executeOperation()` and `executeSubscription()` for those who would like to use directly. 2. add a `perEventExecutor` option to `ExecutionArgs` that allows one to pass a custom context for execution of each execution event, with the opportunity to clean up the context on return, a la graphql#2485 and graphql#3071, addressing graphql#894, which would not require re-coercion of variables. The signature of the `perEventExecutor` option would be: ```ts type SubscriptionEventExecutor = ( validatedExecutionArgs: ValidatedExecutionArgs): PromiseOrValue<ExecutionResult> ``` rather than: ```ts type SubscriptionEventExecutor = ( executionArgs: ExecutionArgs): PromiseOrValue<ExecutionResult> ``` This might be a first step to integrating `subscribe()` completely into `execute()` (see: graphql#3644) but is also a reasonable stopping place.
yaacovCR
pushed a commit
to yaacovCR/graphql-js
that referenced
this pull request
Dec 16, 2025
to safely export buildExecutionContext() as validateExecutionArgs() motivation: this will allow us to: 1. export `executeOperation()` and `executeSubscription()` for those who would like to use directly. 2. add a `perEventExecutor` option to `ExecutionArgs` that allows one to pass a custom context for execution of each execution event, with the opportunity to clean up the context on return, a la graphql#2485 and graphql#3071, addressing graphql#894, which would not require re-coercion of variables. The signature of the `perEventExecutor` option would be: ```ts type SubscriptionEventExecutor = ( validatedExecutionArgs: ValidatedExecutionArgs): PromiseOrValue<ExecutionResult> ``` rather than: ```ts type SubscriptionEventExecutor = ( executionArgs: ExecutionArgs): PromiseOrValue<ExecutionResult> ``` This might be a first step to integrating `subscribe()` completely into `execute()` (see: graphql#3644) but is also a reasonable stopping place.
yaacovCR
pushed a commit
to yaacovCR/graphql-js
that referenced
this pull request
Dec 16, 2025
to safely export buildExecutionContext() as validateExecutionArgs() motivation: this will allow us to: 1. export `executeOperation()` and `executeSubscription()` for those who would like to use directly. 2. add a `perEventExecutor` option to `ExecutionArgs` that allows one to pass a custom context for execution of each execution event, with the opportunity to clean up the context on return, a la graphql#2485 and graphql#3071, addressing graphql#894, which would not require re-coercion of variables. The signature of the `perEventExecutor` option would be: ```ts type SubscriptionEventExecutor = ( validatedExecutionArgs: ValidatedExecutionArgs): PromiseOrValue<ExecutionResult> ``` rather than: ```ts type SubscriptionEventExecutor = ( executionArgs: ExecutionArgs): PromiseOrValue<ExecutionResult> ``` This might be a first step to integrating `subscribe()` completely into `execute()` (see: graphql#3644) but is also a reasonable stopping place.
yaacovCR
pushed a commit
to yaacovCR/graphql-js
that referenced
this pull request
Dec 17, 2025
to safely export buildExecutionContext() as validateExecutionArgs() motivation: this will allow us to: 1. export `executeOperation()` and `executeSubscription()` for those who would like to use directly. 2. add a `perEventExecutor` option to `ExecutionArgs` that allows one to pass a custom context for execution of each execution event, with the opportunity to clean up the context on return, a la graphql#2485 and graphql#3071, addressing graphql#894, which would not require re-coercion of variables. The signature of the `perEventExecutor` option would be: ```ts type SubscriptionEventExecutor = ( validatedExecutionArgs: ValidatedExecutionArgs): PromiseOrValue<ExecutionResult> ``` rather than: ```ts type SubscriptionEventExecutor = ( executionArgs: ExecutionArgs): PromiseOrValue<ExecutionResult> ``` This might be a first step to integrating `subscribe()` completely into `execute()` (see: graphql#3644) but is also a reasonable stopping place.
yaacovCR
pushed a commit
to yaacovCR/graphql-js
that referenced
this pull request
Dec 17, 2025
to safely export buildExecutionContext() as validateExecutionArgs() motivation: this will allow us to: 1. export `executeOperation()` and `executeSubscription()` for those who would like to use directly. 2. add a `perEventExecutor` option to `ExecutionArgs` that allows one to pass a custom context for execution of each execution event, with the opportunity to clean up the context on return, a la graphql#2485 and graphql#3071, addressing graphql#894, which would not require re-coercion of variables. The signature of the `perEventExecutor` option would be: ```ts type SubscriptionEventExecutor = ( validatedExecutionArgs: ValidatedExecutionArgs): PromiseOrValue<ExecutionResult> ``` rather than: ```ts type SubscriptionEventExecutor = ( executionArgs: ExecutionArgs): PromiseOrValue<ExecutionResult> ``` This might be a first step to integrating `subscribe()` completely into `execute()` (see: graphql#3644) but is also a reasonable stopping place.
yaacovCR
pushed a commit
to yaacovCR/graphql-js
that referenced
this pull request
Dec 19, 2025
to safely export buildExecutionContext() as validateExecutionArgs() motivation: this will allow us to: 1. export `executeOperation()` and `executeSubscription()` for those who would like to use directly. 2. add a `perEventExecutor` option to `ExecutionArgs` that allows one to pass a custom context for execution of each execution event, with the opportunity to clean up the context on return, a la graphql#2485 and graphql#3071, addressing graphql#894, which would not require re-coercion of variables. The signature of the `perEventExecutor` option would be: ```ts type SubscriptionEventExecutor = ( validatedExecutionArgs: ValidatedExecutionArgs): PromiseOrValue<ExecutionResult> ``` rather than: ```ts type SubscriptionEventExecutor = ( executionArgs: ExecutionArgs): PromiseOrValue<ExecutionResult> ``` This might be a first step to integrating `subscribe()` completely into `execute()` (see: graphql#3644) but is also a reasonable stopping place.
yaacovCR
pushed a commit
to yaacovCR/graphql-js
that referenced
this pull request
Dec 22, 2025
to safely export buildExecutionContext() as validateExecutionArgs() motivation: this will allow us to: 1. export `executeOperation()` and `executeSubscription()` for those who would like to use directly. 2. add a `perEventExecutor` option to `ExecutionArgs` that allows one to pass a custom context for execution of each execution event, with the opportunity to clean up the context on return, a la graphql#2485 and graphql#3071, addressing graphql#894, which would not require re-coercion of variables. The signature of the `perEventExecutor` option would be: ```ts type SubscriptionEventExecutor = ( validatedExecutionArgs: ValidatedExecutionArgs): PromiseOrValue<ExecutionResult> ``` rather than: ```ts type SubscriptionEventExecutor = ( executionArgs: ExecutionArgs): PromiseOrValue<ExecutionResult> ``` This might be a first step to integrating `subscribe()` completely into `execute()` (see: graphql#3644) but is also a reasonable stopping place.
yaacovCR
pushed a commit
that referenced
this pull request
Dec 22, 2025
to safely export buildExecutionContext() as validateExecutionArgs() motivation: this will allow us to: 1. export `executeOperation()` and `executeSubscription()` for those who would like to use directly. 2. add a `perEventExecutor` option to `ExecutionArgs` that allows one to pass a custom context for execution of each execution event, with the opportunity to clean up the context on return, a la #2485 and #3071, addressing #894, which would not require re-coercion of variables. The signature of the `perEventExecutor` option would be: ```ts type SubscriptionEventExecutor = ( validatedExecutionArgs: ValidatedExecutionArgs): PromiseOrValue<ExecutionResult> ``` rather than: ```ts type SubscriptionEventExecutor = ( executionArgs: ExecutionArgs): PromiseOrValue<ExecutionResult> ``` This might be a first step to integrating `subscribe()` completely into `execute()` (see: #3644) but is also a reasonable stopping place.
yaacovCR
pushed a commit
that referenced
this pull request
Dec 22, 2025
to safely export buildExecutionContext() as validateExecutionArgs() motivation: this will allow us to: 1. export `executeOperation()` and `executeSubscription()` for those who would like to use directly. 2. add a `perEventExecutor` option to `ExecutionArgs` that allows one to pass a custom context for execution of each execution event, with the opportunity to clean up the context on return, a la #2485 and #3071, addressing #894, which would not require re-coercion of variables. The signature of the `perEventExecutor` option would be: ```ts type SubscriptionEventExecutor = ( validatedExecutionArgs: ValidatedExecutionArgs): PromiseOrValue<ExecutionResult> ``` rather than: ```ts type SubscriptionEventExecutor = ( executionArgs: ExecutionArgs): PromiseOrValue<ExecutionResult> ``` This might be a first step to integrating `subscribe()` completely into `execute()` (see: #3644) but is also a reasonable stopping place.
yaacovCR
pushed a commit
to yaacovCR/graphql-js
that referenced
this pull request
Jan 27, 2026
to safely export buildExecutionContext() as validateExecutionArgs() motivation: this will allow us to: 1. export `executeOperation()` and `executeSubscription()` for those who would like to use directly. 2. add a `perEventExecutor` option to `ExecutionArgs` that allows one to pass a custom context for execution of each execution event, with the opportunity to clean up the context on return, a la graphql#2485 and graphql#3071, addressing graphql#894, which would not require re-coercion of variables. The signature of the `perEventExecutor` option would be: ```ts type SubscriptionEventExecutor = ( validatedExecutionArgs: ValidatedExecutionArgs): PromiseOrValue<ExecutionResult> ``` rather than: ```ts type SubscriptionEventExecutor = ( executionArgs: ExecutionArgs): PromiseOrValue<ExecutionResult> ``` This might be a first step to integrating `subscribe()` completely into `execute()` (see: graphql#3644) but is also a reasonable stopping place.
yaacovCR
pushed a commit
that referenced
this pull request
Feb 22, 2026
to safely export buildExecutionContext() as validateExecutionArgs() motivation: this will allow us to: 1. export `executeOperation()` and `executeSubscription()` for those who would like to use directly. 2. add a `perEventExecutor` option to `ExecutionArgs` that allows one to pass a custom context for execution of each execution event, with the opportunity to clean up the context on return, a la #2485 and #3071, addressing #894, which would not require re-coercion of variables. The signature of the `perEventExecutor` option would be: ```ts type SubscriptionEventExecutor = ( validatedExecutionArgs: ValidatedExecutionArgs): PromiseOrValue<ExecutionResult> ``` rather than: ```ts type SubscriptionEventExecutor = ( executionArgs: ExecutionArgs): PromiseOrValue<ExecutionResult> ``` This might be a first step to integrating `subscribe()` completely into `execute()` (see: #3644) but is also a reasonable stopping place.
yaacovCR
pushed a commit
that referenced
this pull request
Feb 23, 2026
to safely export buildExecutionContext() as validateExecutionArgs() motivation: this will allow us to: 1. export `executeOperation()` and `executeSubscription()` for those who would like to use directly. 2. add a `perEventExecutor` option to `ExecutionArgs` that allows one to pass a custom context for execution of each execution event, with the opportunity to clean up the context on return, a la #2485 and #3071, addressing #894, which would not require re-coercion of variables. The signature of the `perEventExecutor` option would be: ```ts type SubscriptionEventExecutor = ( validatedExecutionArgs: ValidatedExecutionArgs): PromiseOrValue<ExecutionResult> ``` rather than: ```ts type SubscriptionEventExecutor = ( executionArgs: ExecutionArgs): PromiseOrValue<ExecutionResult> ``` This might be a first step to integrating `subscribe()` completely into `execute()` (see: #3644) but is also a reasonable stopping place.
yaacovCR
pushed a commit
that referenced
this pull request
Feb 24, 2026
to safely export buildExecutionContext() as validateExecutionArgs() motivation: this will allow us to: 1. export `executeOperation()` and `executeSubscription()` for those who would like to use directly. 2. add a `perEventExecutor` option to `ExecutionArgs` that allows one to pass a custom context for execution of each execution event, with the opportunity to clean up the context on return, a la #2485 and #3071, addressing #894, which would not require re-coercion of variables. The signature of the `perEventExecutor` option would be: ```ts type SubscriptionEventExecutor = ( validatedExecutionArgs: ValidatedExecutionArgs): PromiseOrValue<ExecutionResult> ``` rather than: ```ts type SubscriptionEventExecutor = ( executionArgs: ExecutionArgs): PromiseOrValue<ExecutionResult> ``` This might be a first step to integrating `subscribe()` completely into `execute()` (see: #3644) but is also a reasonable stopping place.
yaacovCR
pushed a commit
that referenced
this pull request
Feb 24, 2026
to safely export buildExecutionContext() as validateExecutionArgs() motivation: this will allow us to: 1. export `executeOperation()` and `executeSubscription()` for those who would like to use directly. 2. add a `perEventExecutor` option to `ExecutionArgs` that allows one to pass a custom context for execution of each execution event, with the opportunity to clean up the context on return, a la #2485 and #3071, addressing #894, which would not require re-coercion of variables. The signature of the `perEventExecutor` option would be: ```ts type SubscriptionEventExecutor = ( validatedExecutionArgs: ValidatedExecutionArgs): PromiseOrValue<ExecutionResult> ``` rather than: ```ts type SubscriptionEventExecutor = ( executionArgs: ExecutionArgs): PromiseOrValue<ExecutionResult> ``` This might be a first step to integrating `subscribe()` completely into `execute()` (see: #3644) but is also a reasonable stopping place.
yaacovCR
pushed a commit
that referenced
this pull request
Feb 24, 2026
to safely export buildExecutionContext() as validateExecutionArgs() motivation: this will allow us to: 1. export `executeOperation()` and `executeSubscription()` for those who would like to use directly. 2. add a `perEventExecutor` option to `ExecutionArgs` that allows one to pass a custom context for execution of each execution event, with the opportunity to clean up the context on return, a la #2485 and #3071, addressing #894, which would not require re-coercion of variables. The signature of the `perEventExecutor` option would be: ```ts type SubscriptionEventExecutor = ( validatedExecutionArgs: ValidatedExecutionArgs): PromiseOrValue<ExecutionResult> ``` rather than: ```ts type SubscriptionEventExecutor = ( executionArgs: ExecutionArgs): PromiseOrValue<ExecutionResult> ``` This might be a first step to integrating `subscribe()` completely into `execute()` (see: #3644) but is also a reasonable stopping place.
yaacovCR
pushed a commit
that referenced
this pull request
Feb 24, 2026
to safely export buildExecutionContext() as validateExecutionArgs() motivation: this will allow us to: 1. export `executeOperation()` and `executeSubscription()` for those who would like to use directly. 2. add a `perEventExecutor` option to `ExecutionArgs` that allows one to pass a custom context for execution of each execution event, with the opportunity to clean up the context on return, a la #2485 and #3071, addressing #894, which would not require re-coercion of variables. The signature of the `perEventExecutor` option would be: ```ts type SubscriptionEventExecutor = ( validatedExecutionArgs: ValidatedExecutionArgs): PromiseOrValue<ExecutionResult> ``` rather than: ```ts type SubscriptionEventExecutor = ( executionArgs: ExecutionArgs): PromiseOrValue<ExecutionResult> ``` This might be a first step to integrating `subscribe()` completely into `execute()` (see: #3644) but is also a reasonable stopping place.
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
executeno longer runs the query algorithm for subscription operations. Rather, subscription operations are performed, as per the spec.subscribeandcreateSourceEventStreamare removed.See additional comments below.