[Bug]: failed /v1/audio/speech calls write no LiteLLM_SpendLogs row (success rows and other routes’ failure rows are written)

快速结论：这个报错通常出现在 LiteLLM Proxy 已经开启 SpendLogs 落库、而 /v1/audio/speech 调用被上游拒绝（例如 voice 参数非法）返回 4xx/5xx 的场景；此时成功调用会写 LiteLLM_SpendLogs，但失败调用不写任何行，导致失败原因既不在 SpendLogs 也不在控制台完整留存。优先做的事是升级到已修复版本并确认失败行被写入。

适用环境：Issue 中确认的环境为 LiteLLM Proxy，版本涉及 v1.100.1、v1.101.0（问题复现）与 v1.105.0（不再复现）；后端使用 Postgres DB 并保留默认 spend logging（disable_error_logs 未设置）；TTS 部署为 Azure Speech（azure/speech/azure-tts-hd），通过名为 tts-latest 的 model group 调用。Issue 未提供操作系统、Python、CUDA、显卡或 PyTorch 版本信息。

最快修复方案：升级到 LiteLLM v1.105.0，并在相同条件下重放一次失败的 POST /v1/audio/speech 调用，确认返回 400 且 LiteLLM_SpendLogs 中出现对应失败行。这是 Issue 中唯一被验证有效的处理方式。

注意事项：Issue 作者没有定位到具体修复提交，也没有测试 v1.102–v1.104，因此无法说明是哪一个版本开始修复的，只能确认 v1.105.0 不复现。另外即使升级后，失败行的 call_type 仍为空字符串，而成功调用写入的是 aspeech；如果依赖 call_type 过滤失败记录，需要改用 request_id 或时间窗口检索。Issue 中提到 #41813 可能不再需要，但这只是推测，未经验证。

问题场景

用户在 LiteLLM Proxy 上启用 Postgres 作为后端数据库、并保留默认 spend logging 的情况下，通过 POST /v1/audio/speech 调用 Azure Speech TTS 模型组（tts-latest，底层为 azure/speech/azure-tts-hd）。当请求参数合法、调用成功返回 200 时，LiteLLM_SpendLogs 会正常写入一行（call_type = aspeech、status = success、spend 正确）；但只要该调用被上游拒绝并返回 400（例如传入不存在的 voice），SpendLogs 中不会出现任何 status = 'failure' 行，无论等待批量写入间隔还是两分钟后都没有记录。

作为对比，同一个 proxy 上的 /v1/audio/transcriptions、/v1/embeddings 和 /v1/ocr 失败时都会写入失败行，并带有 metadata.error_information。因此该问题只影响 /v1/audio/speech 的失败路径。

报错原文

[Bug]: failed /v1/audio/speech calls write no LiteLLM_SpendLogs row (success rows and other routes' failure rows are written)

litellm.BadRequestError: AzureException - …
litellm.proxy.proxy_server.audio_speech(): Exception occured - …
litellm.router.py::async_function_with_fallbacks() - Error occurred while trying to do fallbacks - …

原因分析

根据 Issue 作者的排查，audio_speech 在 proxy_server.py 中抛出 ProxyException 之前确实 await 了 proxy_logging_obj.post_call_failure_hook(...)，而 audio_transcriptions 走的是同样的流程且失败行能正常写入，因此调用链在源代码层面看起来是一致的，问题可能出在更靠后的处理环节。

作者还确认了 _ProxyDBLogger.async_post_call_failure_hook 中的 route gate 理论上应放行，因为 /audio/speech 和 /v1/audio/speech 都在 LiteLLMRoutes.openai_routes 中；同时 DBSpendUpdateWriter.update_database 若抛异常会通过 spend_log_error 以 ERROR 级别输出，但控制台没有出现该行，也没有出现 Spend tracking - update_database failed 或 [Non-Blocking] Error in async_post_call_failure_hook callback。因此可能原因是 hook 在到达 update_database 之前提前返回，或者 payload 在后续环节被静默丢弃且未触发错误日志。Issue 中没有给出根因定位结论。

环境排查

确认 LiteLLM Proxy 版本：Issue 在 v1.100.1 与 v1.101.0 复现，v1.105.0 不再复现；v1.102–v1.104 未被测试。
确认后端数据库为 Postgres，且 spend logging 为默认配置（disable_error_logs 未设置）。
确认 TTS 部署：Azure Speech，model group 为 tts-latest，底层模型 azure/speech/azure-tts-hd。
确认失败请求返回状态码为 400，且响应头中是否存在 x-litellm-call-id（v1.101.0 上失败响应没有任何 x-litellm-* 头）。
检索 SpendLogs 时注意：该版本失败行的 call_type 为空，不能用 call_type 过滤，应改用时间窗口或 error_information 中的错误文本。
OS、Python、CUDA、显卡、PyTorch 版本在 Issue 中未提供，无法据此排查。

解决步骤

将 LiteLLM Proxy 升级到 v1.105.0。
保持与复现时相同的配置：Postgres 后端、默认 spend logging（disable_error_logs 不设置）、Azure TTS 部署与 tts-latest model group。
重放一次会失败的 POST /v1/audio/speech 请求，例如传入不支持的 voice，确认返回 400。
检查该 400 响应是否带有 x-litellm-call-id（v1.105.0 上应出现，v1.101.0 上没有）。
用这个 x-litellm-call-id 去 LiteLLM_SpendLogs 中按 request_id 查询对应失败行。
确认该行为 status: failure、error_information.error_class: BadRequestError、error_code: 400，并包含上游 provider 的错误信息。
若仍不写失败行，再按上述“环境排查”逐项核对版本与配置；Issue 未提供其他已验证的修复手段。

验证方法

在 v1.105.0 上重放同样的失败请求后，检查两点：一是 400 响应头中出现 x-litellm-call-id；二是用该 id 作为 request_id 查询 LiteLLM_SpendLogs，能查到一行 status = 'failure' 的记录，且其中带有 error_information.error_class、error_code: 400 和 provider 的错误消息。如果这两点都满足，说明问题已解决。注意验证时不要用 call_type 过滤失败行，因为失败行的 call_type 为空；成功调用则仍应写入 call_type = aspeech 的行。