Description
With recent versions of Spring for GraphQL and Micrometer, it seems that a regression has been introduced where GraphQL request observations have no parent observation set, whereas the server http observation would be expected.
We initially introduced the GraphQL request observation and its ExecutionRequestObservationContext as RequestReplyReceiverContext. This type of context is meant to be used in cases we need to propagate incoming tracing information (at the transport level) to the observation being created. This is a required step for observation correlation across network boundaries. In the case of the HTTP transport, our implementation would rely on a custom PropagationWebGraphQlInterceptor that extracts tracing information from request headers and copy them to the GraphQL context. As a fallback, would rely on the fact that any current observation would be set as such in the GraphQL context. While this approach worked in the past, it seems that recent changes/fixes broke it.
After reviewing the request instrumentation, I came to the following conclusion:
- the GraphQL request execution is transport agnostic and should not deal with propagation; this means that the observation context should be a simple
Observation.Context - some transports might not support tracing information on a per execution input basis. For example, the WebSocket transport does not support sending headers for each message
- it is the responsibility of the underlying transport to be instrumented; if it is, the current observation should be set as such in the GraphQL context so that it can be used as parent by the main observation. If the underlying transport is not instrumented, tracing propagation will not apply and the request observation will have no parent.
As a result, we should update ExecutionRequestObservationContext and deprecate PropagationWebGraphQlInterceptor as they should not be used anymore as of today.
Thanks @tkmax83 for providing a sample application.