David Elner

@marcotc That PR didn't introduce it, it merely migrated it. It used to exist in this file. History beyond that I don't know off the top of my head. https://github.com/DataDog/dd-trace-rb/pull/795/files#diff-ade263dd4c26c0cd26b8f7956fa5673d5966cd2397d5918a08a30b0eb3b1abf1L55...

In this case, what do you expect to see that you're not seeing? GET calls? Something else?

Okay this is a helpful triage; we'll reassess this instrumentation, see if we can improve upon it. Might follow up later with some questions or updates. Thanks for the heads...

Adding tags like this seems fine, although I have to ask whether adding view and DB time from the Rails tag adds value when presumably these are already traced and...

There could be a few different explanations for this. 1. Truncation is definitely a possibility; either on the trace library side, or the Datadog agent side. 2. SQL quantization in...

So sounds like nothing is happening on the Ruby side which means it's likely the agent. There's not much I can do in this particular library/repo, but we should continue...

Thanks for the request @jrgifford! We'd be happy to have this kind of support, but the honest answer is I don't expect we'll have the capacity for this in the...

Thanks for the report @jerny-lantern. With 1.x, we're changed the behavior of `service`, which I outlined in [this post](https://github.com/DataDog/dd-trace-rb/issues/2086#issuecomment-1156782480). This means GraphQL is not meant to have its own service...

@jerny-lantern The first example is what we want from a data model perspective. However, there's a clear need to be able to produce something like the second example. I hear...

Also I had to update my action items above: I think we should remove the `service_name` option for GraphQL. However, we won't do this until equivalent UI behavior is in...