iOS distributed traces failing without required headers

[jracollins]

Currently iOS traces do not connect with backend traces, and end up being surfaced in Datadog as a single span for the iOS part, with "the backend" creating its own corresponding new trace starting at its ingress point.

I found distributed traces are working from the JS browser SDK, so I compared request headers from each and the breaking difference was two headers not present on requests traced by the iOS SDK.

x-datadog-sampling-priority: 1 
x-datadog-sampled: 1

With these manually added to the requests in the iOS app, the distributed traces work correctly.

These headers are mentioned in the docs:

https://docs.datadoghq.com/real_user_monitoring/connect_rum_and_traces/?tab=browserrum#how-are-rum-resources-linked-to-traces

I am not sure why they are missing, so can these two values just be hardcoded to "1" in the iOS SDK? I am happy to create a PR if that is an accepted solution?

This looks to be a known issue from quite a while ago but wasn't mentioned by support as a potential reason during investigations:

dd-sdk-ios/Sources/Datadog/Tracing/Propagation/TracingHTTPHeaders.swift

Line 16 in 9cdb8fe

// TODO: RUMM-338 support `x-datadog-sampling-priority`. `dd-trace-ot` reference:

I am not sure this is limited to just the Java Agent as mentioned later as it shows up as a single span and in front of our Java agent is an Envoy sidecar from Istio also shipping traces (and that span is also is unconnected to the iOS trace).

[ncreated]

Hello @jracollins 👋 . Thank you a lot for reporting this and we really appreciate your investigation and the level of details! It's hard to reproduce this issue in our own infra, hence it went unnoticed. I made the fix in #575 and it should be available in upcoming release.

[jracollins]

No worries at all @ncreated - and thanks for the quick fix!

[ncreated]

@jracollins this should be now solved in 1.7.0, thanks for help!