Disable distributed OpenTelemetry propagation

[tombruijn]

Prevent OpenTelemetry from sending tracing headers to other applications through HTTP requests.

Use an unconfigured CompositePropagator to disable HTTP propagation headers while maintaining local trace correlation. It is not configured with any other propagators, so it will not add the headers to the outgoing requests.

I hope this fixes the issue with app data being reported to the wrong app, if one app makes a request to another app and they're both instrumented with OpenTelemetry.

To do

• Inform this customer upon release.

Resources

• Internal private dev discussion about the change

[unflxw]

I wonder/worry this might break instrumentations that use propagation for other reasons -- for example, our own BullMQ instrumentation, but also others.

It would be worth running the BullMQ instrumentation's tests (for older BullMQ versions, as the instrumentation is broken on latest BullMQ) with this propagator configuration and seeing if it works.

[unflxw]

It would seem this breaks propagation at large: adding provider.register({propagator: new CompositePropagator()}); (which is what passing a textMapPropagator to the NodeSDK ultimately does) at the top of the beforeEach in the BullMQ instrumentation's tests causes the tests that rely on propagation to fail.

This by itself could be an acceptable breakage, but other instrumentations might rely on propagation as well. We may wish to disable propagation specifically for the HTTP integration, if that's possible.

[backlog-helper]

• This Pull Request has been approved. Can it be merged @tombruijn? - (More info)

---

This is a message from the daily scheduled checks.

New issue guide | Backlog management | Rules | Feedback

[tombruijn]

It would seem this breaks propagation at large: adding provider.register({propagator: new CompositePropagator()}); (which is what passing a textMapPropagator to the NodeSDK ultimately does) at the top of the beforeEach in the BullMQ instrumentation's tests causes the tests that rely on propagation to fail.

This by itself could be an acceptable breakage, but other instrumentations might rely on propagation as well. We may wish to disable propagation specifically for the HTTP integration, if that's possible.

That's weird. If I run the test app we have it does work with the changes in this PR.

Request timeline:

Worker timeline:

[tombruijn]

I don't see a way to disable the trace headers to be disabled in the HTTP instrumentation. Do you think the suggested change is still acceptable?

[unflxw]

That's weird. If I run the test app we have it does work with the changes in this PR.

Ah, yes, for our purposes, the BullMQ instrumentation will work just fine with propagation disabled. It will fail to create a link between the process.bullmq and the publish.bullmq spans, but this is fine, because we don't send span links to the agent.

Actually, I can't think of an use case for propagation that we wouldn't be okay with breaking -- its whole use case is having different processes share the same trace, which is what we want to avoid.

So it's likely okay to merge this as-is, and we'll deal with issues if they arise.