fix(acp): forward W3C trace-context headers to downstream agents

[NiteshDhanpal]

Problem

filter_request_headers (agent_acp_service.py) only forwards x-* headers to the downstream ACP server, so it silently strips W3C traceparent/tracestate/baggage. That detaches the downstream agent's observability trace — and the Temporal workflow/activity it signals — from the ingress trace, so a request can't be followed from the API call (task/create / event/send) to the agent's work. The agent's activity shows up in Tempo as a fresh root with no link back to the gateway.

Verification (infra-staging, rocket-mock-async)

• Confirmed the agent's business↔obs correlation + the Temporal OTel interceptor already stitch workflow → activity → egp/db into one trace.
• Confirmed the only gap is this header strip: the control plane forwards the RPC to the agent's ACP server but drops traceparent, so the agent starts a fresh trace.

Fix

Allow the three W3C trace-context headers (traceparent, tracestate, baggage) through the forward allowlist. They are neither hop-by-hop nor sensitive. With this, event/send (gateway) → agent ACP → workflow → activity → egp/db becomes one continuous trace.

Tests

• Existing header-filter test still passes.
• Added test_forwards_w3c_trace_context_headers pinning the new behavior.
• ruff clean.

🤖 Generated with Claude Code

Greptile Summary

The PR completes W3C trace-context propagation from ingress requests to downstream ACP operations.

• Allows traceparent, tracestate, and baggage through the safe-header filter.
• Extracts trace context directly from the inbound request for every downstream ACP operation.
• Adds focused tests for filtering and case-insensitive extraction.

Confidence Score: 5/5

The PR appears safe to merge.

The previously reported trace-propagation gap is resolved because every downstream ACP operation obtains headers through get_headers, which now extracts W3C context from the request-bound inbound headers.

Important Files Changed

Filename	Overview
agentex/src/domain/services/agent_acp_service.py	Adds case-insensitive W3C header allowlisting and merges ingress trace context into headers used by every downstream ACP operation, resolving the previously reported propagation gap.
agentex/tests/unit/services/test_agent_acp_service.py	Adds focused coverage for forwarding, filtering, case-insensitive extraction, and empty trace-header inputs.

Sequence Diagram

sequenceDiagram
    participant Client
    participant AgentEx as AgentEx ingress
    participant ACP as Downstream ACP agent
    participant Temporal
    Client->>AgentEx: Request with traceparent/tracestate/baggage
    AgentEx->>AgentEx: Extract and filter trace context
    AgentEx->>ACP: JSON-RPC with trace-context headers
    ACP->>Temporal: Start workflow/activity in continued trace

Loading

_{Reviews (3): Last reviewed commit: "Merge branch 'main' into agentex-obs" | Re-trigger Greptile}

[NiteshDhanpal]

Addressed the Greptile P1 (trace propagation incomplete) in 2b65058.

The allowlist change alone only helped event/send — it's the one caller that threads request_headers into get_headers(). task/create, message, streaming and cancel call get_headers(agent) with no request_headers, so filter_request_headers received nothing and traceparent was still dropped for those.

Fix: get_headers now always extracts inbound W3C trace-context (traceparent/tracestate/baggage) from self._request.headers (which it already reads for delegation headers) and forwards it regardless of request_headers — so every downstream operation continues the ingress trace, not just event/send. Added extract_trace_context_headers + unit tests.

[MeeSo-Scale]

what is DD_TRACE_ENABLED in the cluster where this was verified, and in prod? If it differs, this fix silently won't apply where it matters most.

-- My bad just saw the description

[NiteshDhanpal]

what is DD_TRACE_ENABLED in the cluster where this was verified, and in prod? If it differs, this fix silently won't apply where it matters most.

Good point — the environment I'm testing on doesn't have ddtrace enabled.. For envs where it is enabled, this will just be a no-op. Still working through the end-to-end testing for trace propagation and trace correlation for both sync and async paths; the goal is to provide a paved migration path from ddtrace to LGTM for such services

[MeeSo-Scale]

LGTM -- nit - forward_task_to_acp passes no headers, so filter_request_headers never runs on the create path

[NiteshDhanpal]

Re: the create-path nit (forward_task_to_acp passes no headers → filter_request_headers never runs on create) — accurate, and it's covered by 2b65058.

filter_request_headers indeed still doesn't run on the create path (create intentionally doesn't forward arbitrary client x-* headers). But trace-context no longer depends on it: get_headers now unconditionally extracts traceparent/tracestate/baggage from self._request.headers (via extract_trace_context_headers) and forwards them regardless of request_headers. So create_task → get_headers propagates trace context on the create path too — same fix that resolved the P1. No further change needed.

[harvhan]

nit: The new tests cover the two helpers, but the behavior this PR exists for is that get_headers forwards trace context even when the caller passes no request_headers (task/create, message, streaming, cancel). Consider one test that sets mock_request.headers = {"traceparent": "...", "baggage": "..."} and asserts await agent_acp_service.get_headers(sample_agent) includes them, similar to test_get_headers_server_request_id_wins_over_passthrough. That pins the actual wiring rather than just the helper.

[harvhan]

nit: _request is always assigned in __init__, and get_delegation_headers() two lines below dereferences self._request.state unconditionally, so this getattr guard never actually protects anything. Simpler to write dict(self._request.headers) directly.

[stephen-wang24]

lg