Investigating missing Datadog correlation headers in browser RUM and traces

Hello! Struggling to get around a problem with <https://docs.datadoghq.com/real_user_monitoring/connect_rum_and_traces/?tab=browserrum|Connecting RUM to Traces> - docs say that once I enable allowedTracingUrls for datadogRum SDK in my node browser app then it should be able to generate 1st trace in the UI code and correlate everything all the way down. However, the way to verify is given as:

In your browser's developer tools, go to the Network tab.
Check the request headers for a resource request that you expect to be correlated contains the correlation headers from Datadog.```


When I check the headers for the requests I pass through I don't see the specific ones listed mentioned anywhere - is there a step I'm missing? Both UI and server code are correctly sending traces but I don't see the Magic Link Headers being injected anywhere to tie it all together... Should I see them attached to the rum sdk calls (structured like this <https://browser-intake-datadoghq.com/api/v2/rum?ddsource=browser&ddtags=sdk_version%3A5.6.0>..... ) , or on my own API calls??? Docs aren't very clear on it

Headers I should be seeing somewhere:


```x-datadog-trace-id
    Generated from the Real User Monitoring SDK. Allows Datadog to link the trace with the RUM resource.
x-datadog-parent-id
    Generated from the Real User Monitoring SDK. Allows Datadog to generate the first span from the trace.
x-datadog-origin: rum
    To make sure the generated traces from Real User Monitoring don't affect your APM Index Spans counts.
x-datadog-sampling-priority: 1
    To make sure that the Agent keeps the trace.```

As a baseline for understanding your setup: is your application a SPA (independent UI that fetches to an API) or is it a “I render the result every time, fresh reload for every interaction” style?

Hey Carles, thanks for the fast reply! It’s an SPA , API is served through Cloudfront and backed by either plain https or graphql served by AWS API Gateway

Okay! SPAs should work properly. Have you checked if -maybe- Cloudfront is stripping those headers? The headers should be attached to your API call, on the REQUESTS HEADER part (speaking of F12 - Network). I can see those in an example I have available

Yeah if you could pass that example it would be helpful! I’m just not seeing them anywhere…

From my side I see headers like this…

Actually, scratch that - digging into the raw headers I can see them as part of the URL, so then it suggests CloudFront is doing something to strip them off

Exactly! That was my first suspicion :thinking_face:

Thanks Carles - give me some time to dig and see if I can find the offending header stripper and I’ll report back :slightly_smiling_face:

Back again! So I solved the issue with the headers being sent, and in my Lambda I have the headers logged so I can prove they’re coming through. BUT, I don’t seem to be able to actually get a correlation going. The docs are a bit hand wavey on exactly how I should be seeing this stuff all working together. My Lambda is definitely instrumented for APM, as I can see traces and logs being processed for it, but can’t seem to get anything correlating RUM and Trace.

Is there a format the headers should be in when the Lambda receives them? I had assumed that event: { request: { headers {...} } } was correct, but maybe something else is needed? (edited)