Hey, another question on

GraphQLContext

. We currently allow a resolver to set a cookie on the context which we communicate back to the client. Because of the way graphql-java's `ExecutionInput` works though, the cookie gets set on

input.graphQLContext

, but not on the

graphQLContextMap

that we set on the created

ExecutionInput

. In trying to move to using

GraphQLRequestHandler

we're missing the ability to access the context after executing the request (or batch request). Some options I can think of: • add a public method to

GraphQLRequestHandler

that takes an

ExecutionInput

instead of a

GraphQLServerRequest

and context • add a getter for the context to `GraphQLServerResponse`/`GraphQLRepsonse` (but

@JsonIgnore

it to hide it from the serialized json) • do some stuff in an

Instrumentation

to move the cookie from context into

extensions

but then do some kind of post processing to remove the cookie extension from the response before serializing it to the client (don't love this one) • don't leverage

GraphQLRequestHandler

and continue to execute queries via a

GraphQL

object ourselves (would prefer to be able to leverage eg. the batch functionality without reimplementing ourselves) Thoughts on these options? Other ways you can think of to enable this sort of functionality? I'm happy to put together another PR once we agree on direction.

Cookies are tight to transportation (HTTP), while GraphQL execution is transportation agnostic, so ideally no stuff like cookies should be set in the resolvers, what i would advice is to use instrumentations to build some HTTP context as child of GraphQLContext, maybe we can have some hooks to signal when we are about to send a HTTP response, or you can use webFilters and store the HTTPContext in the coroutine context or in the reactor context, that way in the webFilter you would access to it and just set the cookies that are in the context you built

oh thanks, I think having some sort of HTTP context be the child of the GraphQLContext is the right approach -- then I don't need to access the GraphQLContext after the fact, and can use the passed through child context object. will ask more if I run into any problems, thanks!

note that whatever you populate in the webfilter it will be available in the coroutine context thanks to the fixed coroutine context propagation in v6

that sounds cool, where is the logic that propagates from webfilter -> coroutine context?

other option you can try, have a custom implementation of

SpringGraphQLContextFactory

and store the

ServerRequest

and

ServerResponse

object references in the graphQLContextMap, the you would just need to access to your graphQL Context from your data fetchers through the DataFetchingEnvironment and write directly to the response object without a webfilter

yep that's the approach i've taken (though jax-rs equivalent instead of spring as we're in dropwizard) and it appears to work great, thanks for the hints