You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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
asRequestReplyReceiverContext
. 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 customPropagationWebGraphQlInterceptor
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:
Observation.Context
As a result, we should update
ExecutionRequestObservationContext
and deprecatePropagationWebGraphQlInterceptor
as they should not be used anymore as of today.Thanks @tkmax83 for providing a sample application.
The text was updated successfully, but these errors were encountered: