Feature Proposal: separateTraces option for XHR/Fetch instrumentations

[Abinet18]

Propose adding an optional separateTraces configuration flag to XMLHttpRequestInstrumentation and FetchInstrumentation that allows HTTP request spans to start a new root trace instead of inheriting the currently active span's trace context.

Use Case
In browser instrumentation, HTTP requests made inside event handlers (e.g., a button click) are automatically parented to the active interaction span. This is the correct behavior in most cases, but there are scenarios where it is undesirable:

The Issue
When a single user interaction (e.g., button click) triggers HTTP requests to APM-instrumented backends, all spans share one traceId:

Trace (traceId: abc123)
├── click span (RUM)
│ ├── fetch /api/checkout (RUM)
│ │ └── checkout-service (APM)
│ │ └── payment-service (APM)
│ │ └── inventory-service (APM)
│ └── fetch /api/analytics (RUM)
│ └── analytics-service (APM)

BT Assignment: ??? (same BT applied to entire trace)
The problem: APM's Business Transaction correlation logic assigns a BT based on the trace. When multiple backend services with different logical BTs are grouped under one trace:

All APM spans get the same BT (e.g., both checkout-service and analytics-service are tagged with the same BT)
BT rules can't distinguish between different backend operations within the same trace

Proposed API

new XMLHttpRequestInstrumentation({ separateTraces: true })
new FetchInstrumentation({ separateTraces: true })

When separateTraces: true:

Each HTTP request span is created under ROOT_CONTEXT, giving it a new, independent traceId
A reference to the originating span can optionally be preserved via span links

Click Trace (traceId: abc123)
└── click span (spanId: click-001)

Checkout Trace (traceId: def456)
└── fetch /api/checkout (RUM)
links: [
{
traceId: abc123,
spanId: click-001,
type: "parent_interaction"
}
]
└── checkout-service (APM)
└── payment-service (APM)
└── inventory-service (APM)

BT: "Checkout" ✓

Analytics Trace (traceId: ghi789)
└── fetch /api/analytics (RUM)
links: [
{
traceId: abc123,
spanId: click-001,
type: "parent_interaction"
}
]
└── analytics-service (APM)

BT: "Analytics" ✓
Maintaining RUM span relationships
Each fetch/XHR span can have a span link with a link type attribute:

typescript
links: [
{
context: { traceId: "abc123", spanId: "click-001" },
attributes: {
"link.type": "parent_interaction"
}
}

[scheler]

@Abinet18
I spoke with @martinkuba on this last week. he pointed out that, with user-action now being an Event in the new instrumentations in this repo, the parent-child span relationship does not apply. If a relationship between user-action Event and fetch/xhr Span is desired, we should discuss how to model that.

The user-action was never meant to be a Span, the current implementation of user-interaction instrumentation is a stop-gap arrangement until we have Events.

There is also some resemblance of your proposed change to xhr/fetch instrumentations to open-telemetry/opentelemetry-specification#1633 - however, xhr/fetch calls will never be in the middle of a call chain, so the concern with the separation of trust boundary does not apply.

I dont know if the approvers to accept your proposal see this discussion, you might want to create an issue or submit a PR in the repo xhr/fetch instrumentations are part of, to get feedback.

[Abinet18]

@scheler , We are suggesting this change assuming we are on current implementation of user interaction as a span as in the js repo. When the change to event is achieved, we won't need it. I plan to raise this in the browser sig meeting and see if it is accepted before submitting a PR in the js repo.

[martinkuba]

@Abinet18 I think the only instrumentation that could parent the xhr/fetch spans is the user-interaction. I am wondering if we should instead deprecate this instrumentation. We have a new event-based user-action instrumentation under development. Or, is the existing user-interaction instrumentation something you want to keep using?

[Abinet18]

Yes @martinkuba , the event based will be a solution when done but it will take time to migrate to it. Till then we are using the user-interaction instrumentation for tracking such events. I think it depends on whether others will also need it , or how fast the migration can be done