The error metrics is not shown with GraphQL::ExecutionError

[shnmorimoto]

Current behaviour
When we raise GraphQL::ExecutionError like the below document, the error metrics (trace.execute.graphql.errors) is not shown in Datadog.

Error Handling

If other error (ex. StandardError) is raised instead of GraphQL::ExecutionError , the metrics was shown.

Expected behaviour

When we raise GraphQL::ExecutionError , the error metrics is shown in Datadog

Steps to reproduce

Set up the graphql tracing manually.

class Graph::Schema::MySchema < GraphQL::Schema
....
    use(
      GraphQL::Tracing::DataDogTracing,
      service: 'graphql'
    )
...
end

Raise GraphQL::ExecutionError in rescure_from

    rescue_from StandardError do |e|
      Rails.logger.error e.backtrace.join("\n")
      Rails.logger.error e.message
      Sentry.capture_exception e
      raise GraphQL::ExecutionError, "some message"

How does ddtrace help you?

Environment

• ddtrace version: 1.3.0
• Configuration block (Datadog.configure ...):see steps to reproduce
• Ruby version: 3.0.4
• Operating system: ruby:3.0.4-alpine on docker
• Relevant library versions: graphql-ruby 1.13.0

[idanci]

GraphQL::ExecutionError is rescued in graphql-ruby internally and never bubble up resulting in just adding the error to errors key in response and resolving the field to nil. From server's perspective it's not even a error, because it returns status 200 and response including the error in the body.

You can either manually in your rescue_from block use set_error(e) on and actvie span, or if you want it to always be processed by datadog error tracking, add it to the root service span.

[shnmorimoto]

Thanks for the information.

I tried to set set_error
Currently, I got the error in the trace page.

But, errors are not yet available in error tracking.

So, I would like to set set_error root service span also.

It seems already active_root_span was removed
https://github.com/DataDog/dd-trace-rb/blob/v1.0.0.beta1/docs/UpgradeGuide.md#breaking-changes

I guess we can trace parent_id of active_span and get root_span.

I saw the documentation but could not find a way to get SpanOperation from span_id.
https://www.rubydoc.info/github/DataDog/dd-trace-rb/Datadog/Tracing

How do we get root_service_span? And can we set set_error to it?

[idanci]

Datadog::Tracing.active_trace&.active_span&.set_error something like that.

Root span is accessible normally in java. I don't know why it was removed from ruby sdk, inconvenient, but there is not much of a choice.

[shnmorimoto]

Thanks for suggestion!

I tried to set it.
It seems Datadog::Tracing.active_trace&.active_span return same object as Datadog::Tracing.active_span

Rails.logger.info("active span id is #{Datadog::Tracing.active_span&.id}")
Rails.logger.info("root span id is #{Datadog::Tracing.active_trace&.active_span&.id}")

I thought that if active_trace return Datadog::Tracing::TraceSegment as per the documentation, we might be able to use spans in Datadog::Tracing::TraceSegment. But active_trace seems to return Datadog::Tracing::TraceOperation.

https://www.rubydoc.info/github/DataDog/dd-trace-rb/Datadog/Tracing#active_trace-class_method

Therefore, there may be no way to access root_span.

[idanci]

If there are no extra Datadog::Tracing.trace calls within your graphql executor or no extra nested instrumentation enabled, then indeed active_span maybe be the same as active_trace.active_span, but that is not always the case.

[shnmorimoto]

I see. Thanks for the explanation.

[TonyCTHsu]

Chiming in a bit late to provide what I have before digging too deep into this.

In order to make error tracking work, datadog expect the error to be tagged at the service entry span (in short, the first span on flamegraph with change of colour.). According to the snapshot provided, it seems like the implementation is tagging the error on the second span instead of the first one.

I was also surprised that the active span in rescue_from block is not the service entry span, but this could vary based on different user cases.

GraphQL endpoint is advised to return 200 response with errors field provided. GraphQL::ExecutionError is a friendly object to help you accomplish that without crashing your application. Hence GraphQL::ExecutionError would be rescued and preventing being bubbled up. Other error, such as StandardError, would be bubbled up and recorded at the service entry span.

[TonyCTHsu]

👋 Hi @shnmorimoto , it looks like the issue have been clarified, do you think we could close the issue for now?

[shnmorimoto]

Yeah, we can close this ticket.
Thanks a lot @TonyCTHsu @idanci