This commit fixes the observability instrumentation for data fetchers
when the return type is of `CompletionStage`. Prior to this commit, the
instrumentation of `CompletionStage` return values as
`DataFetcherResult` would wrap the asynchronous value twice.
Closes gh-676
Prior to this commit, a partial fix in a56ff6e introduced proper
relationships between request and data fetcher observations by tracking
them in a local concurrent map. This fix is incomplete as data fetcher
operations are not set as current in the ThreadLocal or reactive
contexts when the actual DataFetcher is executed.
We cannot use the global GraphQLContext for DataFetcher observations,
as it is shared for the entire GraphQL request (and no thread safe).
This commit makes the Instrumentation instrument DataFetcher and make
them return a `DataFetcherResult` that holds a
`g.s.DataFetchingEnvironment#getLocalContext` with a reference to the
current data fetcher observation. A temporary fix is also applied in
`ContextDataFetcherDecorator` to merge both global and local contexts
when capturing a `ContextSnapshot` to be applied for the data fetching
operation.
Fixes gh-676
See gh-688
Prior to this commit, the `GraphQlObservationInstrumentation` would
organize the parent/child relationship between data fetcher observations
by setting the current observation under a well-known key in the global
GraphQL context.
In some cases, the order of execution and the scheduling of operations
does not reflect the actual operation hierarchy as defined by the
GraphQL `ExecutionStepInfo`. This would result in traces where data
fetching operations are set with incorrect parent/child relationships.
This commit ensures that data fetcher observations have their parent set
with the expected one, by keeping track of active observations and using
the `ExecutionStepInfo` path as a key.
Fixes gh-676
Prior to this commit, the request execution observation would have a
context of type `RequestReplyReceiverContext` to directly deal with
tracing propagation at the transport level. This approach doesn't work
anymore as the parent observation is not properly set on the resulting
trace, even if it is manually set in the instrumentation.
This commit revisits the request observation setup and turns its context
into a regular `Observation.Context`. Tracing propagation should be
dealt with directly at the transport level by an underlying observation.
This is the case already for Spring Framework HTTP server observations.
As a result, the `PropagationWebGraphQlInterceptor` is deprecated with
no replacement and should not be used anymore.
Fixes gh-675
Prior to this commit, the `GraphQlObservationInstrumentation` was
incorrectly setting up the parent observation for both request execution
and data fetching observations.
In the case of the request execution, we were not looking into the
`GraphQLContext` for an existing observation - this commit ensures that
if such an observation exists, it is set as the parent.
As for the data fetching observation, we were incorrectly assuming that
the parent of all data fetching operations was the request execution
one, whereas data fetching operations can be nested. This commit ensures
that we only rely on the current observation in the GraphQL context.
Fixes gh-611
Dropping this the dedicated resolver for @Argument Map<String, Object>
leaves it to ArgumentMethodArgumentResolver and
ArgumentsMethodArgumentResolver to handle the case of
Map<String, Object>, treating it either as a raw argument value for a
named argument, or as the full raw arguments map.
Closes gh-548
Validate an individual method parameter when it's annotated with
Spring's @Validated rather than with @Valid, in which case method
validation does not validate the parameter.
Closes gh-571
Perform the check for whether validation for a HandlerMethod is needed
earlier and only once rather than in the constructor of
DataFetcherHandlerMethod.
Make the validation helper passed to DataFetcherHandlerMethod stateful,
so that validation groups are also determined once on startup.
See gh-571
