Repository navigation
Bug: Streaming responses don't capture response_id or model_version #5812
Description
Problem
In streaming.py, the accumulate_streaming_response() function initializes response_id and model to None (lines 53-54) but never populates them from the streaming chunks. The accumulation loop (lines 56-83) never reads chunk.response_id or chunk.model_version.
This means streaming responses will always have null for gen_ai.response.id and gen_ai.response.model.
The non-streaming path correctly captures both in utils.py:886-890:
if getattr(response, "response_id", None):
span.set_data(SPANDATA.GEN_AI_RESPONSE_ID, response.response_id)
if getattr(response, "model_version", None):
span.set_data(SPANDATA.GEN_AI_RESPONSE_MODEL, response.model_version)Files
sentry_sdk/integrations/google_genai/streaming.py—accumulate_streaming_response()
Acceptance Criteria
- Streaming chunks are checked for
response_idandmodel_version gen_ai.response.idandgen_ai.response.modelare populated on streaming spans- Test added to verify streaming responses capture these fields
Reacted by sentry-junior
Activity
linear-code commentedon Mar 24, 2026
PY-2218
NIK-TIGER-BILL commentedon Mar 30, 2026
Bahtya commentedon Apr 6, 2026
I'd like to work on this. The fix is straightforward — extract
response_idandmodel_versionfrom streaming chunks in the accumulation loop, usinggetattrto safely handle missing attributes. I've identified the exact location insentry_sdk/integrations/google_genai/streaming.py. Happy to submit a PR if this approach looks correct.zkasuran commentedon Aug 11, 2026
I hit this on 2.67.0 and verified it end to end. Would you like me to pick it up? A patch is
ready if so.
Confirmation that both attributes are lost on every streaming call, not just some. I ran the
same content through the real integration twice, once as a whole
GenerateContentResponseand once as a chunk sequence, then diffed the
gen_ai.*attributes on the chat span. Sixresponse shapes: plain text, reasoning plus cached tokens, a tool call, a
MAX_TOKENSfinish, metadata only on the final chunk, then no usage metadata at all.
Nothing else diverges. Text, finish reasons, tool calls and all five token counts match the
non-streaming path in every shape, so it is just the two fields.
AsyncModels.generate_content_streamis affected the same way.
Also confirmed against real Gemini traffic rather than fixtures: on
gemini-2.5-flasheverychunk carries both
response_idandmodel_version(4/4 chunks) and the values are stableacross the stream. Worth knowing for the accumulation rule, because
modelVersionis notalways the requested id. Asking for
gemini-flash-latestreturnedmodel_versionofgemini-3.6-flash, which is exactly the casegen_ai.response.modelis there to record.Two notes on the fix if it is useful:
Reading the last non-
Nonevalue rather than the first matters. Gemini repeats both fields onevery chunk in real traffic, but this repo's own streaming fixture puts them on the first chunk
only, so a first-wins read would pass the tests while a chunk that omits the field would still
be able to clear a good value under last-wins-without-guard.
model = event.message.model or modelin the
anthropicintegration is the same convention.The streaming fixture at
tests/integrations/google_genai/test_google_genai.pyalready carries"responseId": "response-id-stream-123"and"modelVersion": "gemini-1.5-flash", so the datais already on the way in. No streaming test asserts either attribute reaches the span, which is
why 510 passing tests did not catch this. Adding those two assertions to the existing streaming
test makes it fail before the fix, plus one new async streaming test where only the first chunk
carries the metadata.
I have the change, the two assertions and the async test locally against
3fbf49bwith thegoogle_genai suite green (511 passed, 1 skipped),
ruff checkandruff formatclean, andmypy sentry_sdkshowing no new errors. Happy to open the PR once a maintainer confirms theapproach, per CONTRIBUTING.
sentry-junior commentedon Nov 12, 2026
Reproduced in getsentry/repro#71. Draft fix #8260 was closed without merging.