北京
这是 DEV 夏季 Bug Smash 活动的参赛作品，目标是清理 Sentry 的排行榜。
项目是 Sentry 自家的 Python SDK：getsentry/sentry-python。它的google_genai集成把 Gemini 调用变成gen_ai.chatspan，让 AI 监控面板展示 token 数、finish reason、成本和回答的模型。同一个 SDK 还负责错误监控，所以对许多团队来说，这是生产环境里代理实际行为的唯一记录。
我去修复一个存在五个月的旧 Issue，关于两个缺失的 span 属性。结果发现比“缺失”更糟。
Bug 还是性能改进？
Issue #5812 准确描述了：流式响应从未捕获response_id或model_version。在google_genai/streaming.py的accumulate_streaming_response中，两个局部变量被声明了，代码也读取了文本、finish reason、工具调用和五个 token 计数，但最后把这两个声明过的局部变量交给 span 时，从未真正读取它们：
usage_data = Noneresponse_id = None # 声明model = None # 声明for chunk in chunks:# ... 从 chunk 里读取了其他所有东西# response_id 和 model: 从未被触及accumulated_response = AccumulatedResponse(id=response_id, # 永远是 Nonemodel=model, # 永远是 None同一个集成里的非流式路径会从响应中读取这两个值，所以一个集成的两半行为不一致。
动手修复前，我想知道真实影响范围，于是构建了一个差分探针。它把相同内容通过真实集成发送两次：一次作为完整的GenerateContentResponse，一次作为块序列，然后对比落在 chat span 上的gen_ai.*属性。测试了六种响应形状：纯文本、reasoning 加缓存 token、工具调用、MAX_TOKENS结束、仅在最后一块有元数据、完全没有 usage 元数据。
结果：流式路径上gen_ai.response.id在 6/6 种情况中丢失，gen_ai.response.model在 6/6 种情况中丢失。其余属性没有分歧。
这个 bug 意味着流式调用（实际生产中很常见）在监控中丢失了模型和响应标识，无法对应到具体的 Gemini API 调用。修复就是正确读取 chunk 中的这两个字段。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
