[Bug] OpenAI-compatible streaming request returns 502 when upstream proxy reports EOF

[DolphinZZZZZ]

What happened / 发生了什么

When using an OpenAI-compatible provider with gpt-5.5, AstrBot sometimes receives a 502 error during streaming chat completion.

The upstream proxy/server log shows that the actual upstream request failed with EOF when forwarding to:

https://chatgpt.com/backend-api/codex/responses

AstrBot only receives:

Error code: 502 - {'error': {'message': 'Upstream request failed', 'type': 'upstream_error'}}

Provider configuration names, account names, API key names, session IDs, and message contents are redacted. The involved models are gpt-5.5 and gpt-5.4.

Reproduce / 如何复现？

1. Configure an OpenAI-compatible provider using gpt-5.5.
2. Enable streaming output.
3. Send a normal chat request from the QQ official adapter.
4. The upstream proxy occasionally returns EOF and AstrBot logs a 502 request error.

In the observed case, the request body was small, around 23 KB, so this does not look like a large-context request failure.

AstrBot version / AstrBot 版本

v4.26.0-beta.1

OS / 系统

Windows

Message platform / 消息平台

The failing request came from the QQ official adapter.

Relevant AstrBot log, with session ID and message content redacted:

[2026-06-21 23:47:11.041] [Core] [INFO] [core.event_bus:79]:
[default] [AstrBot (qq_official)] [redacted-session-id]: [At:qq_official] [redacted-message-content]

The response path also shows the QQ official C2C sender:

[qqofficial.qqofficial_message_event:437]:
Message sent to C2C: {...}

So the observed message channel was qq_official / QQ official C2C.

AstrBot logs / AstrBot 日志

[2026-06-21 23:48:31.645] [Core]
[WARN]
[v4.26.0-beta.1] [runners.tool_loop_agent_runner:554]:
Chat Model [redacted-provider]/gpt-5.5 request error: Error code: 502 - {'error': {'message': 'Upstream request failed', 'type': 'upstream_error'}}

Traceback (most recent call last):
  File "<ASTRBOT_ROOT>/astrbot/core/agent/runners/tool_loop_agent_runner.py", line 509, in _iter_llm_responses_with_fallback
    async for attempt in retrying:
  File "<PYTHON_ENV>/site-packages/tenacity/asyncio/__init__.py", line 170, in __anext__
    do = await self.iter(retry_state=self._retry_state)
  File "<PYTHON_ENV>/site-packages/tenacity/asyncio/__init__.py", line 157, in iter
    result = await action(retry_state)
  File "<PYTHON_ENV>/site-packages/tenacity/_utils.py", line 111, in inner
    return call(*args, **kwargs)
  File "<PYTHON_ENV>/site-packages/tenacity/__init__.py", line 393, in <lambda>
    self._add_action_func(lambda rs: rs.outcome.result())
  File "<PYTHON_ENV>/concurrent/futures/_base.py", line 449, in result
    return self.__get_result()
  File "<PYTHON_ENV>/concurrent/futures/_base.py", line 401, in __get_result
    raise self._exception
  File "<ASTRBOT_ROOT>/astrbot/core/agent/runners/tool_loop_agent_runner.py", line 513, in _iter_llm_responses_with_fallback
    async for resp in self._iter_llm_responses(
  File "<ASTRBOT_ROOT>/astrbot/core/agent/runners/tool_loop_agent_runner.py", line 473, in _iter_llm_responses
    async for resp in stream:
  File "<ASTRBOT_ROOT>/astrbot/core/provider/sources/openai_source.py", line 1218, in text_chat_stream
    ) = await self._handle_api_error(
  File "<ASTRBOT_ROOT>/astrbot/core/provider/sources/openai_source.py", line 1092, in _handle_api_error
    raise e
  File "<ASTRBOT_ROOT>/astrbot/core/provider/sources/openai_source.py", line 1205, in text_chat_stream
    async for response in self._query_stream(payloads, func_tool):
  File "<ASTRBOT_ROOT>/astrbot/core/provider/sources/openai_source.py", line 551, in _query_stream
    stream = await self.client.chat.completions.create(
  File "<PYTHON_ENV>/site-packages/openai/resources/chat/completions/completions.py", line 2814, in create
    return await self._post(
  File "<PYTHON_ENV>/site-packages/openai/_base_client.py", line 1931, in post
    return await self.request(cast_to, opts, stream=stream, stream_cls=stream_cls)
  File "<PYTHON_ENV>/site-packages/openai/_base_client.py", line 1716, in request
    raise self._make_status_error_from_response(err.response) from None
openai.InternalServerError: Error code: 502 - {'error': {'message': 'Upstream request failed', 'type': 'upstream_error'}}

Upstream server/proxy logs / 上游服务器日志

Sensitive account fields have been redacted.

{
  "kind": "request_error",
  "message": "Post \"https://chatgpt.com/backend-api/codex/responses\": EOF",
  "platform": "openai",
  "model": "gpt-5.5"
}

Related HTTP response returned to AstrBot:

request error: Error code: 502 - {'error': {'message': 'Upstream request failed', 'type': 'upstream_error'}}

Expected behavior / 期望行为

If this is considered an upstream/provider-side failure, AstrBot should ideally surface a clearer error message or retry/fail over more gracefully during streaming requests.

For example:

• Preserve the upstream EOF information if available.
• Make it clearer that the 502 came from the upstream provider/proxy.
• Avoid losing useful error context during streaming fallback handling.

Additional context / 补充信息

The same provider setup also uses gpt-5.4 in related model configuration, but provider names, account names, API key names, session IDs, and message contents are intentionally omitted from this report.

We tested whether the issue was caused by an overlong conversation context. After enabling AstrBot context compression/truncation, the request size was reduced significantly, but the EOF/502 error could still occur. In one observed failed request, the request body was only around 23 KB. Therefore, this report is not about an input-too-large failure.

[dosubot]

Hi @DolphinZZZZZ! I'm Dosu and I'm helping the AstrBotTeam team.

根据代码分析，这个 502 错误的处理流程如下：

当前 AstrBot 的重试机制

AstrBot 对 HTTP 502 已有两层重试：

1. Provider 层自动重试：retry_provider_request() 会对状态码 429/500/502/503/504 自动重试，最多 5 次，使用指数退避+抖动策略 [1] [2]。
2. Agent 层 fallback：如果 5 次重试全部失败，异常传播到 _iter_llm_responses_with_fallback，系统会尝试切换到备用 provider [3]。

关键限制：流式输出场景

如果 502 发生在流式输出开始之前（即 client.chat.completions.create() 建立连接时），上述重试和 fallback 都能正常生效。但从你的堆栈来看，错误发生在 _query_stream 中创建流的阶段 [4]，此时尚未开始流式输出，所以 fallback 机制应该会触发。

关于 EOF 错误信息丢失

你提到的 upstream EOF 信息确实会丢失。_handle_api_error 方法在检测到连接错误时会记录日志，但 openai.InternalServerError（502）不属于连接错误类型——它是一个正常的 HTTP 响应，只是状态码为 502。因此 EOF 细节（来自上游代理的 JSON body）不会被特殊处理或记录 [5]。

你的场景分析

你的情况是上游代理在转发到 chatgpt.com/backend-api/codex/responses 时遇到 EOF，返回 502 给 AstrBot。AstrBot 的 provider 层重试应该会重试该请求最多 5 次。如果仍然失败，日志只显示最终的 502 错误信息，而不包含 upstream EOF 的根因。

关于你的建议

你提出的改进方向是合理的：

• 保留 upstream 错误 body 中的详细信息（如 EOF）作为日志的一部分
• 在 WARN 日志中标明 502 来自 upstream proxy 而非 AstrBot 内部错误

不过，核心问题仍然在上游代理侧——EOF 意味着代理与 chatgpt.com 之间的连接被异常关闭，AstrBot 侧能做的主要是改善错误可观测性。如果你配置了备用 provider（fallback），AstrBot 在重试耗尽后应该会自动切换。

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.

[DolphinZZZZZ]

补充定位结果：

该问题的直接原因不是模型不可用，而是当前 OpenAI-compatible 适配路径固定调用 Chat Completions 接口：

client.chat.completions.create(...)

因此请求会被发送到 Chat Completions endpoint。

但相关模型/上游实际支持的是 Responses API endpoint，两者的请求路径和 payload 格式不同，不能通过简单修改 API Base URL 解决。

原因是 OpenAI SDK 的 Chat Completions client 会继续拼接 Chat Completions 路径；如果把 API Base URL 手动改成 Responses endpoint，最终请求路径仍会错误。

实测现象：

• Chat Completions endpoint 请求失败
• Responses API endpoint 请求成功
• 服务端日志显示成功请求使用的是 Responses API 协议

因此，这是 OpenAI-compatible Chat Completions 适配器与 Responses API 上游之间的协议不匹配问题，而不是单纯的账号、模型名或 API Base URL 配置问题。

[DolphinZZZZZ]

解决方案已提 PR：#8955

该 PR 新增独立的 OpenAI Response provider，使需要 Responses API 的场景可以通过单独 provider 走 client.responses.create，同时保留现有 OpenAI Compatible 的 chat-completions 行为不变。