Apollo GQL integration not tracing calls

[ersen-lw]

Describe the bug

I noticed the GQL calls are not being traced in RUM. The events have 0 resources tracked.
The GQL requests is missing the following headers:

_dd-custom-header-graph-ql-operation-name: {OP Name}
_dd-custom-header-graph-ql-operation-type: query 
_dd-custom-header-graph-ql-variables: {} 

Reproduction steps

My app is a mix of REST and GQL. They share the same OkHttp client. The OkHttp client has the DatadogInterceptor added to it. I then added the DatadogApolloInterceptor to the Apollo client.

I observed that when both is added then the GQL call will not have these headers.

_dd-custom-header-graph-ql-operation-name: {OP Name}
_dd-custom-header-graph-ql-operation-type: query 
_dd-custom-header-graph-ql-variables: {} 

It will instead have these headers

x-apollo-operation-name:         OpName
x-datadog-origin:                rum
x-datadog-parent-id:             ID
x-datadog-sampling-priority:     1
x-datadog-tags:                  _dd.p.dm=-0,_dd.p.tid=ID
x-datadog-trace-id:              ID

When I remove the DatadogInterceptor then I am able to see GQL headers.

However I noticed that after only including the DatadogApolloInterceptor that I still do not see the GQL call traced in the resources tab.

Logcat logs

I don't see any warning or error logs from datadog related to this issue

Expected behavior

• GQL call should be traced
• I should be able to share a OkHttpClient between Apollo and REST
• REST should use the DatadogInterceptor
• GQL should use DatadogApolloInterceptor

Affected SDK versions

3.3.0

Latest working SDK version

N/A

Did you confirm if the latest SDK version fixes the bug?

Yes

Kotlin / Java version

2.2.21

Gradle / AGP version

gradle-8.13 / AGP-8.12.2

Other dependencies versions

okhttp 4.12.0

Device Information

Tested so far on a Pixel 8 emulator running Android 15 (API 35)

Other relevant information

No response

[jonathanmos]

@ersen-lw those _dd-custom headers are just for internal use. The reason that you see them when removing the DatadogInterceptor is that it is the interceptor that is actually removing them after it extracts the relevant information. DatadogInterceptor is necessary in order to forward the GQL to Rum.

Can you please check that the data is being consumed by the sdk? if you put a breakpoint in the DatadogInterceptor you should see the graphql values in the attributes, and if you put a breakpoint in the RumResourceScope you should have them in the graphQL variable

[jonathanmos]

Could you please try the following on the dashboard just to verify whether events have arrived:

Inside Rum Explorer, select Resources in the dropdown and run the following query:
@resource.graphql.operationName:*

Also, when you say that graphql is not visible - are you checking for it when Resources is selected in the explorer (as in the above)?

[ersen-lw]

Hi @jonathanmos

Thanks for the reply

Can you please check that the data is being consumed by the sdk? if you put a breakpoint in the DatadogInterceptor you should see the graphql values in the attributes, and if you put a breakpoint in the RumResourceScope you should have them in the graphQL variable

I put a breakpoint in DatadogInterceptor and RumResourceScope I can see the GQL fields.

"_dd.graphql.operation_name" -> "OpName"
"_dd.graphql.operation_type" -> "query"
"_dd.graphql.variables" -> "{}"

Inside Rum Explorer, select Resources in the dropdown and run the following query:
@resource.graphql.operationName:*

I can see them with that query and this has revealed why i didn't see the requests.

This is separate issue where the screen start view is a little delayed and the resource call is actually on background rather than under the actual screen name.

And these events are just millseconds apart. On Datadog it shows 5:26:59 pm for both of them

[jonathanmos]

hi @ersen-lw , so if I understand correctly you now see the events but there is an issue with the timing? I think it may be best to open a support ticket (and mention this one) so that we can investigate.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity and has the awaiting-response label.

It will be closed if no further activity occurs within 3 days.