bug in @graphql-tools/wrap #1954
Comments
|
Hi! @maapteh are you able to recreate this bug with just a regular sdl schema? Is this a bug with wrap or just the way wrap works? |
|
It happens because we wrap all root-level resolvers with |
|
Should be fixed by batched executor which is (loosely) planned for v7, to be based on Gatsby-style batch execution This right now is working as designed as far as I can tell but there is room of course for design improvement. Batch execution is one solution, maybe there are others? |
|
Of course there already is HttpLinkDataLoader which batches as one request not necessarily one operation |
|
Actually, I am not 100% on whether batch execution fixes this issue. The executor will still be called multiple times, so similar test may fail, but because multiple root fields or multiple operations can be sent as one, there will be only one network request. Would that solve this issue? |
|
When the testcase for #1955 succeeds we know if it will solve it :) |
|
Why do you need the executor to be called once if it uses Data loader to batch and send one request? |
|
Because now our dataloader is not called in the same request/operation. Dataloader only works when it happens in the same tick. But i think its a bug in combination apollo and our used modules and will go back there! thanks Yaacov. Sorry for reporting here :) |
|
The point is of that issue is that when you wrap the schema with |
Merged
|
Seems to have been addressed within graphql-modules as documented in linked issue above. Closing this issue for now! When query batching lands, see #1965, another possible workaround may be available. |
yaacovCR
added a commit
that referenced
this issue
Aug 31, 2020
WIP: When `batch` is set to true for a given subschemaConfig, batches all delegated root fields into a combined request passed to the executor. Moreover, batches all requests to a given subschema into the minimum number of requests, collecting queries and mutations separately, preserving operation order. Distributes properly pathed errors to the originating requests. Adapted from Gatsby query batcher by @vladar. Caveats: * Uses a Dataloader under the hood, which is created anew upon each request -- relies on a unique context argument per request to make this happen! * Does not pass `info` argument to the batched executor call, disabling any executors that used extensions annotated onto info. TODO: - Add testing! - Extensions support should be added by a custom option? Related: gatsbyjs/gatsby#22347 (comment) #1710 (comment) #1959 (comment) #1954
yaacovCR
added a commit
that referenced
this issue
Aug 31, 2020
WIP: When `batch` is set to true for a given subschemaConfig, batches all delegated root fields into a combined request passed to the executor. Moreover, batches all requests to a given subschema into the minimum number of requests, collecting queries and mutations separately, preserving operation order. Distributes properly pathed errors to the originating requests. Adapted from Gatsby query batcher by @vladar. Caveats: * Uses a Dataloader under the hood, which is created anew upon each request -- relies on a unique context argument per request to make this happen! * Does not pass `info` argument to the batched executor call, disabling any executors that used extensions annotated onto info. TODO: - Add testing! - Extensions support should be added by a custom option? Related: gatsbyjs/gatsby#22347 (comment) #1710 (comment) #1959 (comment) #1954
Merged
yaacovCR
added a commit
that referenced
this issue
Aug 31, 2020
WIP: When `batch` is set to true for a given subschemaConfig, batches all delegated root fields into a combined request passed to the executor. Moreover, batches all requests to a given subschema into the minimum number of requests, collecting queries and mutations separately, preserving operation order. Distributes properly pathed errors to the originating requests. Adapted from Gatsby query batcher by @vladar. Caveats: * Uses a Dataloader under the hood, which is created anew upon each request -- relies on a unique context argument per request to make this happen! * Does not pass `info` argument to the batched executor call, disabling any executors that used extensions annotated onto info. TODO: - Add testing! - Extensions support should be added by a custom option? Related: gatsbyjs/gatsby#22347 (comment) #1710 (comment) #1959 (comment) #1954
Merged
yaacovCR
added a commit
that referenced
this issue
Aug 31, 2020
WIP: When `batch` is set to true for a given subschemaConfig, batches all delegated root fields into a combined request passed to the executor. Moreover, batches all requests to a given subschema into the minimum number of requests, collecting queries and mutations separately, preserving operation order. Distributes properly pathed errors to the originating requests. Adapted from Gatsby query batcher by @vladar. Caveats: * Uses a Dataloader under the hood, which is created anew upon each request -- relies on a unique context argument per request to make this happen! * Passed `info` argument from first executor call to the batched executor call, making info argument unreliable. TODO: - Add testing! Related: gatsbyjs/gatsby#22347 (comment) #1710 (comment) #1959 (comment) #1954 fix
yaacovCR
added a commit
that referenced
this issue
Aug 31, 2020
WIP: When `batch` is set to true for a given subschemaConfig, batches all delegated root fields into a combined request passed to the executor. Moreover, batches all requests to a given subschema into the minimum number of requests, collecting queries and mutations separately, preserving operation order. Distributes properly pathed errors to the originating requests. Adapted from Gatsby query batcher by @vladar. Caveats: * Uses a Dataloader under the hood, which is created anew upon each request -- relies on a unique context argument per request to make this happen! * Passed `info` argument from first executor call to the batched executor call, making info argument unreliable. TODO: - Add testing! Related: gatsbyjs/gatsby#22347 (comment) #1710 (comment) #1959 (comment) #1954
yaacovCR
added a commit
that referenced
this issue
Aug 31, 2020
WIP: When `batch` is set to true for a given subschemaConfig, batches all delegated root fields into a combined request passed to the executor. Moreover, batches all requests to a given subschema into the minimum number of requests, collecting queries and mutations separately, preserving operation order. Distributes properly pathed errors to the originating requests. Adapted from Gatsby query batcher by @vladar. Caveats: * Uses a Dataloader under the hood, which is created anew upon each request -- relies on a unique context argument per request to make this happen! * Passed `info` argument from first executor call to the batched executor call, making info argument unreliable. TODO: - Add testing! Related: gatsbyjs/gatsby#22347 (comment) #1710 (comment) #1959 (comment) #1954
yaacovCR
added a commit
that referenced
this issue
Aug 31, 2020
WIP: When `batch` is set to true for a given subschemaConfig, batches all delegated root fields into a combined request passed to the executor. Moreover, batches all requests to a given subschema into the minimum number of requests, collecting queries and mutations separately, preserving operation order. Distributes properly pathed errors to the originating requests. Adapted from Gatsby query batcher by @vladar. Caveats: * Uses a Dataloader under the hood, which is created anew upon each request -- relies on a unique context argument per request to make this happen! * Passed `info` argument from first executor call to the batched executor call, making info argument unreliable. TODO: - Add additional testing! Related: gatsbyjs/gatsby#22347 (comment) #1710 (comment) #1959 (comment) #1954
yaacovCR
added a commit
that referenced
this issue
Aug 31, 2020
WIP: When `batch` is set to true for a given subschemaConfig, batches all delegated root fields into a combined request passed to the executor. Moreover, batches all requests to a given subschema into the minimum number of requests, collecting queries and mutations separately, preserving operation order. Distributes properly pathed errors to the originating requests. Adapted from Gatsby query batcher by @vladar. Caveats: * Uses a Dataloader under the hood, which is created anew upon each request -- relies on a unique context argument per request to make this happen! * Passed `info` argument from first executor call to the batched executor call, making info argument unreliable. TODO: - Add additional testing! Related: gatsbyjs/gatsby#22347 (comment) #1710 (comment) #1959 (comment) #1954
yaacovCR
added a commit
that referenced
this issue
Aug 31, 2020
WIP: When `batch` is set to true for a given subschemaConfig, batches all delegated root fields into a combined request passed to the executor. Moreover, batches all requests to a given subschema into the minimum number of requests, collecting queries and mutations separately, preserving operation order. Distributes properly pathed errors to the originating requests. Adapted from Gatsby query batcher by @vladar. Caveats: * Uses a Dataloader under the hood, which is created anew upon each request -- relies on a unique context argument per request to make this happen! * Passed `info` argument from first executor call to the batched executor call, making info argument unreliable. TODO: - Add additional testing! Related: gatsbyjs/gatsby#22347 (comment) #1710 (comment) #1959 (comment) #1954
yaacovCR
added a commit
that referenced
this issue
Aug 31, 2020
WIP: When `batch` is set to true for a given subschemaConfig, batches all delegated root fields into a combined request passed to the executor. Moreover, batches all requests to a given subschema into the minimum number of requests, collecting queries and mutations separately, preserving operation order. Distributes properly pathed errors to the originating requests. Adapted from Gatsby query batcher by @vladar. Caveats: * Uses a Dataloader under the hood, which is created anew upon each request -- relies on a unique context argument per request to make this happen! * Passed `info` argument from first executor call to the batched executor call, making info argument unreliable. TODO: - Add additional testing! Related: gatsbyjs/gatsby#22347 (comment) #1710 (comment) #1959 (comment) #1954
yaacovCR
added a commit
that referenced
this issue
Aug 31, 2020
When `batch` is set to true for a given subschemaConfig, batches all delegated root fields into a combined request passed to the executor. Moreover, batches all requests to a given subschema into the minimum number of requests, collecting queries and mutations separately, preserving operation order. Distributes properly pathed errors to the originating requests. Adapted from Gatsby query batcher by @vladar. Caveats: * Uses a Dataloader under the hood, which is created anew upon each request -- relies on a unique context argument per request to make this happen! * Passed `info` argument from first executor call to the batched executor call, making info argument unreliable. Related: gatsbyjs/gatsby#22347 (comment) #1710 (comment) #1959 (comment) #1954
ardatan
pushed a commit
that referenced
this issue
Sep 1, 2020
* enable batch execution When `batch` is set to true for a given subschemaConfig, batches all delegated root fields into a combined request passed to the executor. Moreover, batches all requests to a given subschema into the minimum number of requests, collecting queries and mutations separately, preserving operation order. Distributes properly pathed errors to the originating requests. Adapted from Gatsby query batcher by @vladar. Caveats: * Uses a Dataloader under the hood, which is created anew upon each request -- relies on a unique context argument per request to make this happen! * Passed `info` argument from first executor call to the batched executor call, making info argument unreliable. Related: gatsbyjs/gatsby#22347 (comment) #1710 (comment) #1959 (comment) #1954 * fix(delegate): pass extensions to executor/subscriber
|
Available in 6.2.0! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This is a follow up of issue created at Urigo/graphql-modules#1295
I still have to understand how, but wanted to create the ticket as soon as possible.
The text was updated successfully, but these errors were encountered: