[Bug] Streaming requests that time out mid-stream are logged as success (not reported as failures)

快速结论：LiteLLM 代理在流式请求过程中，上游供应商超时中断会导致该请求被错误记为成功（HTTP 200），造成失败指标严重低估。优先排查并修复 async_data_generator 中的异常处理路径，确保调用失败回调而非成功回调。

适用环境：LiteLLM Proxy v1.83.x（已知 1.83.14 受影响）；涉及 /v1/chat/completions 与 /v1/messages 流式接口；已验证的供应商包括 AWS Bedrock、Vertex AI、Azure OpenAI、OpenAI。

最快修复方案：暂无确认的一步修复方案。Issue 中仅确认了问题定位（common_request_processing.py 中 async_data_generator 的 except 块需要调用失败处理器），尚未验证具体补丁代码。

注意事项：维护者提到会在周六发布前修复 /v1/messages 路径问题；/v1/chat/completions 路径看似已修复，但需验证具体修复版本。生产环境中建议同时依赖日志告警而非仅依赖指标。

问题场景

该问题发生在通过 LiteLLM 代理转发流式请求时。当上游供应商在流式响应中途停滞（mid-stream stall），超过配置的读取超时时间后，超时异常在 async_data_generator 中被抛出——但这发生在 HTTP 200 状态行已发送给客户端之后。因此 LiteLLM 错误地触发了成功日志回调，而不是失败回调。

报错原文

[Bug] Streaming requests that time out mid-stream are logged as success (not reported as failures)

httpx.ReadTimeout: Timeout on reading data from socket

async_data_generator(): Exception occured - Timeout on reading data from socket

No failure logging callback fires
litellm.proxy.failed_requests.metric.count is NOT incremented

原因分析

根本原因是 LiteLLM 的流式响应逻辑将 HTTP 状态码提交与上游数据读取分离处理。当上游在流式传输中途超时时，HTTP 200 状态已经提交给客户端，此时在生成器内部抛出的异常无法改变已发送的 HTTP 状态码。异常处理逻辑未能正确区分这种”提交后失败”场景，继续沿用了成功路径的日志回调，导致失败指标 litellm_proxy_failed_requests_metric 未递增，失败日志回调也未触发。

环境排查

确认 LiteLLM 代理版本：建议记录当前版本并关注修复版本发布（Issue 提及 1.83.x 受影响）
评估流式接口类型：/v1/chat/completions 与 /v1/messages 在相同版本上可能表现不一致（Issue 确认在 1.83.14 和最新 staging 中 /v1/messages 仍可复现）
检查读取超时配置：timeout 与 stream_timeout 配置项是否正确设置
记录供应商类型：AWS Bedrock、Vertex AI、Azure OpenAI、OpenAI 均为已验证受影响

解决步骤

复现问题：通过代理发起 stream=true 请求，让上游在流式响应中途停滞超过读取超时时间，观测请求是否被记录为 200 成功。
定位异常路径：检查 LiteLLM 的 common_request_processing.py 文件中 async_data_generator 的 except 块逻辑——修复方向是让此处的失败处理调用失败回调（failure handler）而非让成功回调继续执行。
可优先尝试修复 /v1/messages 路径：维护者声明该路径在 1.83.14 和最新内部版本上均有问题，并计划在下一版本修复。
升级 LiteLLM 至修复版本：关注 Issue 关联 PR 或发布说明中关于此问题的修复记录。

验证方法

修复后，重复复现步骤，确认满足以下条件即证明问题已解决：

litellm.proxy.failed_requests.metric.count（Prometheus litellm_proxy_failed_requests_metric）在超时故障时正确递增
失败日志回调（failure logging callback）被触发
流式响应中断在监控中不再静默计入成功请求