What

Records the model provider's response id on the LLM trace span as the standard OpenTelemetry GenAI attribute gen_ai.response.id.

For Volcengine Ark this id equals the x-request-id response header — the most useful identifier when correlating with the provider's logs / filing tickets.

Why it's done this way

• ADK builds its LlmResponse from the litellm response's message/model/usage but drops response.id, so the tracer never sees it.
• A pure litellm callback can read the id, but litellm runs success callbacks detached from the OTel context (verified: get_current_span() is non-recording there), so it can't attach the id to the LLM span.
• So a self-contained tracing module wraps LiteLLMClient.acompletion in-context (where the raw response is available, inside ADK's generate_content span) and sets gen_ai.response.id on the current span.

Scope / safety

• New file veadk/tracing/telemetry/litellm_response_id.py + one lazy registration line in OpentelemetryTracer (same pattern as the existing patch_google_adk_telemetry).
• No agent.py change, no model subclass. The wrap is applied only when a VeADK OpenTelemetry tracer is created; with no tracer nothing is patched, and when patched-but-not-recording it's a no-op.
• Non-streaming is covered (the default); the streaming wrapper has no stable id at this point, so it's skipped.

Verified locally (real Ark call)

With a tracer enabled, the generate_content span's gen_ai.response.id exactly equals the live Ark response.id:

SPAN gen_ai.response.id: ['021780383672524f789d4d4546194a16e88624aed779d5ca0707c']
REAL ark response.id   : ['021780383672524f789d4d4546194a16e88624aed779d5ca0707c']
RESULT: PASS

🤖 Generated with Claude Code