feat: Propagate OTel tracing context from client to server through websocket

[lhchavez]

Why

The River Python library already injects OpenTelemetry trace context (traceparent/tracestate) into outgoing TransportMessages on the client side, but the server never extracts this context or creates corresponding server-side spans. This means distributed traces are broken across the websocket boundary — the server has no visibility into which client trace initiated a given RPC.

What changed

src/replit_river/rpc.py

• Added TransportMessageTracingGetter — the extraction counterpart to the existing TransportMessageTracingSetter. Implements the OTel Getter protocol to read traceparent and tracestate from a TransportMessage.tracing field.

src/replit_river/server_session.py

• In _open_stream_and_call_handler(), the server now extracts the incoming trace context from the first message of each stream using TraceContextTextMapPropagator.extract().
• Creates a SERVER span (named river.server.<method_type>.<service>.<procedure>) that is a child of the client's CLIENT span, with attributes for service name, procedure name, method type, stream ID, and client ID.
• Runs the RPC handler within the extracted trace context via _run_handler_with_tracing(), so any downstream OTel instrumentation within the handler automatically inherits the correct parent trace.
• The server span is ended and status set (OK/ERROR) after the handler completes.

tests/v1/test_opentelemetry.py

• Updated existing span count assertions to account for both client and server spans.
• Added 6 new test cases:
  • test_rpc_trace_propagation — verifies same trace ID, parent-child relationship, span kinds
  • test_subscription_trace_propagation — verifies propagation for subscriptions
  • test_upload_trace_propagation — verifies propagation for uploads
  • test_stream_trace_propagation — verifies propagation for bidirectional streams
  • test_server_span_has_attributes — verifies span attributes on the server span
  • test_multiple_rpcs_have_independent_traces — verifies independent RPCs get independent traces

Test plan

All 67 existing tests pass, including the 6 new trace propagation tests:

$ uv run pytest tests/ -v
67 passed in 8.76s

Key verifications in the new tests:

• Client and server spans share the same trace_id
• Server span's parent.span_id matches client span's span_id
• Client spans have SpanKind.CLIENT, server spans have SpanKind.SERVER
• Server spans carry correct river.* attributes
• Independent RPCs produce independent traces (different trace IDs)

Revertibility

This change is safe to revert — it only adds new behavior (server-side span creation) without modifying the wire protocol or any existing client behavior.

~ written by Zerg 👾

[lhchavez]

Superseded by a simpler approach that propagates OTel context (traceparent, tracestate, baggage) via standard HTTP headers on the WebSocket upgrade request, rather than per-RPC tracing.

~ written by Zerg 👾