fix(otel): fall back user.id onto span extras when EVENT_ONLY key is missing

[DmitriiK]

Summary

• When GENERATE_CONTENT_EVENT_ONLY_EXTRA_ATTRIBUTES_CONTEXT_KEY cannot be imported from opentelemetry-instrumentation-google-genai, merge log_only_extra_attributes (including user.id) into GENERATE_CONTENT_EXTRA_ATTRIBUTES_CONTEXT_KEY instead of silently dropping them.
• Preserves the EVENT_ONLY path when the constant exists.
• Fixes user.id silently dropped when GENERATE_CONTENT_EVENT_ONLY_EXTRA_ATTRIBUTES_CONTEXT_KEY is missing #6361

Context

opentelemetry-instrumentation-google-genai through 1.0b0 only exports the span extras key. ADK’s except (ImportError, AttributeError): pass meant session.user_id never reached Cloud Trace / GenAI spans on the instrumentor path (Vertex Agent Engine).

Trade-off: user.id lands on generate_content spans when the event-only channel is unavailable (slightly broader than “log-only”), which is preferable to dropping identity entirely until instrumentation ships the EVENT_ONLY key (opentelemetry-python-genai#24).

Test plan

• With instrumentor active and EVENT_ONLY constant absent, generate_content spans include user.id from session.user_id
• With a mock that provides EVENT_ONLY key, behavior unchanged (attrs go to event-only channel)
• Manual: Agent Engine / local run + Trace Explorer filter user.id=<value> on generate_content spans

Made with Cursor

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[rohityan]

Hi @DmitriiK , Thank you for your contribution! It appears you haven't yet signed the Contributor License Agreement (CLA). Please visit https://cla.developers.google.com/ to complete the signing process. Once the CLA is signed, we'll be able to proceed with the review of your PR. Thank you!

[DmitriiK]

@rohityan
submitted.
thanks

[RKest]

Hi @DmitriiK,

Thank you for your contribution,

Could you please share what's your use-case for user.id on spans is?

Some trace backends don't play nice with PII, hence the preference for storing it in logs only, but admittedly it's not the cleanest solution.