Shane Krueger
Shane Krueger
Oh, because you can select fields IF the response is a certain type, as in this example from the GraphQL spec: ```gql # only returns the field 'age' when the...
Since the type isn't known until it is resolved, it isn't known with certainty which fields will execute. We could also say this is true of any field -- if...
I’m not inclined to. We can always add it later.
The `UnhandledExceptionContext` is also called from the execution strategy, and there the `ExecutionOptions` are not available to be passed to the unhandled exception context (since `ExecutionContext` does not hold a...
I don’t understand why we would purposely add a property that can only be populated for errors at the start of the request, but at no other time, when the...
It just seems like a bad design to have to write error logging code like this: ```cs var query = errorContext.Context?.Document.Source.ToString() ?? errorContext.ExecutionOptions!.Query; ``` Because this won't work: ```cs var...
Especially when all the options are valid and unchanged for an entire execution.
What if you wanted to log some other property from ExecutionOptions? It would not be possible.
I have not thought it through fully, but I would consider something like that. It seems like a lot of unnecessary copying of variables.
Maybe I can create an example PR we can both review together (when you have time; no urgency).