Merge branch 'pratik/otel-phase8-log-correlation' into pratik/otel-phase9-metric-gap-fill

OpenTelemetryPlan/09-data-collection-reference.md

@@ -213,6 +213,11 @@ Controlled by `trace_peer` in `[telemetry]` config. **Enabled by default** (high
 | `peer.proposal.receive`   | —      | PeerImp.cpp | Consensus proposal received from peer |
 | `peer.validation.receive` | —      | PeerImp.cpp | Validation message received from peer |
 
+A `—` parent means the span is a fresh trace root (`kConsumer`): it is started
+via `SpanGuard::rootSpan()` at the inbound-message entry point and never
+inherits an ambient span left active on the peer thread, so it does not nest
+under an unrelated transaction's trace.
+
 **Where to find**: Tempo → TraceQL: `{resource.service.name="xrpld" && name=~"peer.*"}`
 
 **Grafana dashboard**: _Peer Network_ (`peer-network`)

OpenTelemetryPlan/Phase3_taskList.md

@@ -100,6 +100,10 @@
 - Use `SpanGuard::span(TraceCategory::Transactions, "tx", "receive")` factory
   (Phase 1c replaced macros with the SpanGuard factory pattern)
 
+> **Note**: The `tx.receive` guard is `.detached()` before being moved into the
+> `RcvCheckTx` job so its Scope is popped on the peer thread, not leaked to the
+> worker (else later peer messages would inherit this transaction's trace).
+
 **Key modified files**:
 
 - `src/xrpld/overlay/detail/PeerImp.cpp`
@@ -123,6 +127,9 @@
     - Create `tx.process` span
     - Set attributes: `tx_hash`, `tx_type`, `local` (whether from RPC or peer)
     - Record whether sync or async path is taken
+    - `.detached()` the guard before storing it in `TransactionStatus::span`,
+      since it is applied on a batch worker thread — this pops the Scope on the
+      origin thread and stops later work inheriting this transaction's trace
 
   - In `doTransactionAsync()`:
     - Capture parent context before queuing