Wrong context to field resolver

[b-jsshapiro]

I'm seeing a weird bug. I've got middleware applied in my server which adds fields to the context structure. If I breakpoint the query handler, I can see that the desired (modified) context is getting passed.

The return type on this query handler is [T!]. I have a field resolver on T.id. If I breakpoint this field resolver, the context that is passed is not the correct context. I have tested this on other fields with the same result.

Any idea why the context is not getting passed to the field resolver correctly? Things I should look for?

Thank you!

[glasser]

Are you able to share code that reproduces this (ideally as a series of instructions starting with git clone or a demo on codesandbox.io)?

I'm not sure what you mean by a "query handler", FWIW.

[b-jsshapiro]

Are you able to share code that reproduces this (ideally as a series of instructions starting with git clone or a demo on codesandbox.io)?

Unfortunately I'm buried in patent lawyers today. I'll try to get it reduced to that can reasonably be cloned and tested.

I'm not sure what you mean by a "query handler", FWIW.

I mean a field resolver on the Query type. That is: the server-side entry point for a query operation. The main reason I mention this is that I can see the correct context there, which means that the middleware and the modification to the context structure is happening correctly - the problem has to be somewhere in the resolver recursion or in the construction of the data structure that the resolver recursion is obeying.

My guess is that the resolver data structure is somehow getting mangled. I've seen this part of the resolver algorithm working correctly in the past, so I'm pretty sure it's not a problem in the resolver algorithm itself. The thing that has changed is that I am using mergeSchema to merge two partial schemas into a single result along with the final resolver covering both. It would not surprise me to learn that I am missing some requirement on the input schemas or the input resolvers that is needed for a successful merge.

"hip deep"

ied

[glasser]

I would definitely expect the same context value to be passed to all resolvers, so yeah, looking forward to a reproduction!

[b-jsshapiro]

@glasser Sorry for the delay. Finally winnowed this down to something manageable. Assuming I got this right in my quick and dirty hack-down, you should find that the hand-constructed AST in src/API.ts redefines the type MessedUp verbatim in MergeDynamicSchema. It then calls mergeSchemas, providing the dynamic AST document and the actual resolver (the initial call to makeExecutableSchema passes {} for resolvers.

Fire up GraphIQL and invoke the GetMessedUp query. At the first debugger point, you'll see that the passed _context object is the one you'd expect based on the middleware at src/ApolloServer.ts:AddToContext. The litmus test is whether the boolField property is present in the context object. Continue, and you'll see that at the second debugger point (in the field handler for id, the context argument doesn't have that field or the dummmy field given at the call to the ApolloServer constructor.

It's probably going to turn out that I've done something glaringly stupid, either in the setup for the call to mergeSchemas or in the initial makeExecutableSchema call, but I'm obviously not seeing it. We may end up needing to bring Dotan in on this.

Here is the repo

[glasser]

I'll try to set some time aside to investigate more deeply soon, but this sure does seem like more of a graphql-tools issue than an apollo-server issue (mergeSchemas comes from graphql-tools even though it is re-exported by AS).

[b-jsshapiro]

I’d agree, but I’ve looked (by hand) at the data structures in a debugger, and they look okay. Do you know of any working examples that use mergeSchemas?

…

On Mon, Mar 1, 2021 at 2:59 PM David Glasser ***@***.***> wrote: I'll try to set some time aside to investigate more deeply soon, but this sure does seem like more of a graphql-tools issue than an apollo-server issue (mergeSchemas comes from graphql-tools even though it is re-exported by AS). — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#4947 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQPXV7QQVMQSP4UEBZR5YNTTBQL6PANCNFSM4YBG2TQQ> .

[glasser]

There's a lot going on in your reproduction. Especially given that we think this is more likely to be a graphql-tools problem than an apollo-server problem, can you try to make it have fewer external dependencies? For example, it looks like the context field in question is added by graphql-middleware, a package I'm only dimly familiar with. Can you remove graphql-middleware from the reproduction?

You can also probably make it simpler to test by dropping all the express stuff and just running await apolloServer.executeOperation({query: "query { whatever query }"}) so that just running the program in Node calls the query.

BTW I think this Discussions thing is supposed to work differently: just respond to my message in the same thread instead of making new subthreads each time.

[b-jsshapiro]

Just to close this out, it was user error. I completely misunderstood what graphql-middleware actually does. The behavior I was seeing was actually correct. I now understand how to accomplish what I was trying to do, which is to provide a context generator to the ApolloServer() constructor. The one unfortunate part of this is that there doesn't seem to be any easy way to do different things to the context depending on the operation type.

[glasser]

What do you mean by operation type?