Description
Distributed Tracing built-in to Sentry landed with the addition of Sentry for Performance Monitoring, the SDKs started creating a sentry-trace header for out going HTTP requests. Backend SDKs became aware of those and further propagated the trace information, as well as adding it to any outgoing events: errors or transactions.
For the most part a trace-id is created when a transaction (event used for performance monitoring) is created. And while the transaction exists (and bound to the scope), that trace-id is propagated through HTTP integrations.
With other products landing such as Session Replay, the need to connect a Replay throughout the whole call chain became more prominent. We can do that today if we rely on sentry-trace being propagated but that requires performance monitoring being enabled. That was a constraint to the initial deliverable of having Replay show up on backend errors:
- [Epic] Replay: Connect backend errors to Replays #45529
- rfc(decision): Linking Backend Errors With Replays rfcs#60
This issue aims to decouple trace propagation and transactions or the performance product. So errors, replays, etc can be linked together across from the frontend to backend services.
# Initial action points
- [ ] SDKs define a `trace-id` and assign to the scope
- [ ] Propagate it downstream similar to how we do when a transaction is bound to the scope
- [ ] How does this play when OTel is used?
- [ ] TODO