[rtemperini]

Summary

Promote an operator-selected allowlist of caller context onto agent spans, so traces can be filtered by an opaque user identifier, conversation thread, or ticket. Follows #1734 / #1737.

Both runtimes use the upstream baggage-to-span processors. Allowlisted A2A message.metadata is promoted into baggage before the invocation span starts, so the invocation and descendant spans share one path. Python uses the common A2A telemetry wrapper for ADK, LangGraph, CrewAI, and OpenAI Agents.

This update removes the PR's unrestricted a2a.message.metadata.* export path flagged in review and integrates the feature with current main's telemetry setup.

Configuration

controller:
  traceContextKeys:
    - {from: sub, to: user.id}
    - thread_id

The Helm value sets KAGENT_TRACE_CONTEXT_KEYS on the controller, which forwards that policy to managed kagent runtimes. Direct runtime configuration accepts comma-separated keys or JSON strings and {from, to} mappings. The previous draft's otel.tracing.contextKeys / otel.traces.contextKeys setting is replaced by controller.traceContextKeys to fit the current chart.

• Empty allowlist disables promotion. Other metadata is never exported by this feature.
• Existing non-empty destination baggage wins. Empty and non-scalar metadata is skipped.
• Destination attribute names are used as configured. The policy is capped at 32 mappings and 64 characters per key, and parsing is cached for the process lifetime.
• Runtime identity remains authoritative where the request processors set it. A Harness cannot enable or widen the operator's allowlist.
• Use opaque identifiers such as OIDC sub, never names or email addresses. Hashing belongs at the gateway or Collector; leftover hash mappings are rejected instead of emitting plaintext.
• Cross-process baggage remains separately opt-in through OTEL_PROPAGATORS=tracecontext,baggage on each participating process. Current kagent's tracecontext-only default is preserved, and controller OTEL_* overrides remain process-local.
• Value truncation uses the SDK's OTEL_SPAN_ATTRIBUTE_VALUE_LENGTH_LIMIT.

No CRD or API changes. See docs/architecture/trace-context.md for configuration and propagation details.

Validation

• Go race checks passed for telemetry, A2A executors/server, and all translator packages.
• 133 Python core and ADK executor tests passed, including common-handler coverage for all four Python runtime profiles.
• All 327 Helm chart tests passed.
• Python lint/format and whitespace checks passed.

Regression coverage checks disabled promotion, allowlisted invocation/model attributes, rejected unrelated metadata, preserved trusted identity, real protobuf metadata decoding, and request-context cleanup. No live Kubernetes deployment was performed.

[krisztianfekete]

Thanks, added a few initial comments!

[rtemperini]

Thanks, added a few initial comments!

Thanks for the review @krisztianfekete , just updated with your comments, let me know if anything else required

[rtemperini]

@krisztianfekete thanks for the reviews, I've added a few updates, let me know if should I take a look on anything else

[rtemperini]

@krisztianfekete I merged main to clear the conflict with the new OTEL env forwarding. Could you take another look when you have a moment? The earlier review comments should still be the open questions.

[krisztianfekete]

Before we go deeper on the details though, I think we can get to the same behaviour with a lot less code by using upstream building blocks.

Both runtimes ship a baggage -> spanattribute processor, each taking a filter/predicate, which is basically what MergeCallerContextAttributes + the attributes span processor are doing by hand.

If we then promote allowlisted A2A message.metadata keys into baggage at the executor boundary rather than reading them as a second source with its own precedence rule, we'd have one code path instead of two, and metadata-sourced values would survive subagent hops as well. That would also let us drop most of the policy layer to where OTel already puts it: value truncation is OTEL_SPAN_ATTRIBUTE_VALUE_LENGTH_LIMIT, renaming can be done via a collector transformation, and hashing is really an collector or gw concern.

I'd rather not hardcode am unprefixed set, as to: is operator config, not caller input, so prefixing it doesn't really defend against anything, and right now it makes gen_ai.conversation.id unreachable even though our own ADK executor already sets it.

[rtemperini]

@krisztianfekete I reworked this around the upstream baggage-to-span processors and promote allowlisted metadata into baggage at the executor, so there is one path. The custom hash/prefix/merge layer is gone; leftover hash mappings fail closed. Could you take another look when you have a moment?

[rtemperini]

Hi @krisztianfekete I've rebased and fixed conflicts with the latests main rebase, can you take a look on this when you have a minute, will be good to address this to be able to have the proper context attributes propagation. Thanks in advance

[rtemperini]

Hi @krisztianfekete, I rebased onto the latest main and fixed the conflicts. The new telemetry stack is kept, and the caller context promotion sits on top of it. Can you take a look when you have a minute? Thanks

[rtemperini]

Hi @EItanya @supreme-gg-gg I rebased this again onto the latest main and fixed the conflicts. The checks that can run from the fork are green, can you take a look when you have a minute, or let me know if anything looks off? Thanks in advance

[github-actions]

This pull request has been marked as stale because of no activity in the last 15 days. It will be closed in the next 5 days unless it is tagged "no stalebot" or other activity occurs.

[rtemperini]

Thanks @moezdil, I removed the unrestricted metadata export and added regression coverage. The PR is also updated for current main. Could you and @krisztianfekete take another look?

Let me know if there is anything else to take a look and thanks again for the review