请教：OpenAI 上游 server_error/流式业务失败场景下，自动重试有什么推荐方案？

例行检查

• 我已确认目前没有完全相同的 issue
• 我已确认我已升级到最新版本（当前使用 calciumion/new-api:latest）
• 我已完整查看过项目 README，并搜索过现有 issue/PR
• 我理解并愿意跟进此 issue，协助测试和提供反馈
• 我理解并认可上述内容，并理解项目维护者精力有限

问题/需求描述

想请教一下：对于 OpenAI 上游偶发的服务端报错，new-api 目前有没有更推荐的“自动重试”方案？如果没有，是否考虑补一套更稳妥的策略？

我这次遇到的现象是：下游机器人侧会偶发拿到类似下面这种 OpenAI 风格的报错文案：

An error occurred while processing your request. You can retry your request, or contact us through our help center at help.openai.com if the error persists. Please include the request ID ...

这类报错我查了下，在 OpenAI 语义里通常更接近 500 / server_error。

但是结合我们这次线上现象来看，问题没有那么简单：

---

这次实际排查到的现象

1. 我们是 自建 new-api + 机器人下游 的场景。
2. 机器人出问题的那一段时间里，下游看起来像是“上游服务端报错了”。
3. 但我去查 new-api 所在机器日志时发现：
   • 在本次对应时间窗里，/v1/chat/completions 这条链路在 new-api 网关层未必会出现明确的 500/503；有时候从网关日志上看还是 200。
   • 也就是说，下游看到的是失败/异常语义，但网关层不一定总能把它表现成一个可直接重试的非 200 状态码。
4. 另外，我也查到同一天别的时间段里，new-api 的确出现过一小段连续 503，但那一段和这次机器人报错的时间窗并不一致，所以不能简单等同。

---

我目前理解到的几个相关点

我看了仓库里现有的讨论，感觉下面几个 issue / PR 是“接近但不完全一样”的：

• #1562 请求加入自动重试和连接超时时间配置
• #2989 流式空回记录为成功，未触发重试
• #3142 Bug: avoid committing HTTP 200 for Responses stream failures before the first downstream write

我的理解是：

1. 如果上游明确返回 500/502/503，现在 new-api 的自动重试逻辑是比较容易处理的；
2. 真正麻烦的是这种“下游语义失败，但网关层不一定拿到明确非 200”的情况，例如：
   • 流式先建连成功，后面才在事件里失败；
   • 上游返回了 OpenAI 风格的 server_error 文案，但在 new-api 当前链路里没有被稳定映射成可重试错误；
   • 或者最终表现成“空回 / 提前断流 / 业务失败但 transport 成功”。

---

想请教维护者几个问题

1. 对于 OpenAI 风格 server_error / 500 类错误，目前你更推荐的自动重试配置是什么？
2. 对于 网关层是 200，但实际业务失败 的情况，new-api 现在有没有比较推荐的处理方式？
3. 是否考虑增加一种更通用的策略，例如：
   • 对上游返回体里的 server_error 做更明确识别；
   • 对“空回 / 提前断流 / 首 token 前失败”做统一标记并触发重试；
   • 区分“可以安全重试”和“可能已经计费，不适合自动重试”的场景；
   • 给日志里补充更清晰的“本次是否属于可重试上游故障”的判断信息。
4. 如果这是设计上就无法完全自动判断的问题，维护者会建议用户在生产环境里怎么配，才能在“减少失败”和“避免重复计费”之间取得比较好的平衡？

---

我这边更希望的方向

如果可以，我更希望 new-api 后续能在这类场景里做到下面几点中的一部分：

1. 明确区分 transport success 和 business success；
2. 对 OpenAI / Responses / 流式场景下的失败，给出更一致的错误归类；
3. 给自动重试更多“可配置但有默认推荐值”的策略，而不是只靠用户自己猜；
4. 日志里最好能直接看出来：
   • 这次失败有没有命中自动重试；
   • 为什么没有重试；
   • 是状态码问题、流式问题、空回问题，还是上游 server_error 问题。

如果维护者愿意，我可以继续补更具体的日志样本，或者按你建议的方式再抓一轮更精确的对照数据。

Start with the /v1/chat/completions path and compare the behavior described in #2989 and #3142, including streaming failures and responses that remain HTTP 200. Done means an agreed, testable retry classification that explains how server_error, empty responses, early disconnects, and possible duplicate billing should be handled.