[Bug]Codex 兼容性问题：/v1/responses 流式响应未正常结束

[sandleft]

版本 / Version

2.0.3

部署方式 / Deployment

其他 / Other

问题描述 / What happened?

Codex 兼容性问题：/v1/responses 流式响应未正常结束

问题描述

新版 Codex 强制要求 wire_api = "responses"，即所有请求必须走 /v1/responses 端点，不再支持 /v1/chat/completions。WindsurfAPI 目前没有实现该端点，导致 Codex 无法使用。

期望

希望官方在 src/server.js 中原生支持 /v1/responses 端点，并正确实现流式事件序列，以兼容新版 Codex。

复现步骤 / Steps to reproduce

### 复现步骤

1. 在 Codex `config.toml` 中配置 WindsurfAPI 为自定义 provider
2. 发送任意对话请求
3. 报错：`unexpected status 404 Not Found: POST /v1/responses not found`

### 临时修复方案（已验证非流式可用，流式仍有问题）

在 `src/server.js` 中手动添加 `/v1/responses` 路由，将请求转换为 `chat/completions` 格式处理：

- 非流式（`stream: false`）：已正常返回 Responses API 格式的 JSON，测试通过
- 流式（`stream: true`）：响应中途断开，Codex 报错 `stream disconnected before completion: stream closed before response.completed`

### 流式问题分析

Codex 要求 SSE 流必须包含完整的事件序列才能正常结束，目前的适配层将 `chat/completions` 的 SSE 格式转换为 Responses API 格式时，`response.completed` 事件未能可靠发出，导致 Codex 判定流异常中断。

日志 / Logs

模型 / Model

gpt

环境 / Environment

• WindsurfAPI（Docker 部署，3 实例 + nginx 负载均衡）
• 客户端：OpenAI Codex（最新版）
• 系统：Windows 11

[dwgx]

合实施完了 你临时方案的方向是对的 但流式那块缺事件 让小克劳德把完整序列补上了

关键是 response.completed 不管 finish_reason 是 stop 还是 tool_calls 都会发 上游错的话发 event:error 然后关 SSE 不再 hang Codex

实测 gemini-2.5-flash + stream → 完整 9 个事件 最后 response.completed 含 output + usage

跟 @lengxii #56 是同一线 一起关了 多谢你提的详细 repro 和分析 流式那段对得上

[sandleft]

流式响应问题仍未解决

环境：

• WindsurfAPI v2.0.4（Docker 3实例 + nginx）
• Codex Desktop 0.125.0-alpha.3
• Windows 11
• 模型：gpt-5.4-xhigh / gemini-2.5-flash 均复现

现象：
服务端日志显示 Chat: cache HIT 后立即 Client disconnected mid-stream, aborting upstream，
Codex 客户端报 stream disconnected before completion: stream closed before response.completed，
重试 5 次后放弃。

非流式（stream: false）可以正常返回，流式必现。

期望：/v1/responses 流式 SSE 序列能可靠发出 response.completed 事件。

[dwgx]

codex-rs/codex-api/src/sse/responses.rs:418 那条 EOF 分支会在没解析到 response.completed 就关流时抛 stream closed before response.completed。而 codex 的 serde 期望 response.completed（以及 response.created / response.in_progress / response.failed）这类生命周期事件的 payload 把 Response 对象包在 response 子字段下：

{"type":"response.completed","response":{"id":"resp_...","status":"completed","output":[...],"usage":{...}}}

之前的代码把 object / id / status / output 这些字段平铺在 type 同级。codex 反序列化时把它当作 unknown 事件静默 drop，跑到 EOF 还没看到合格的 Completed → 报错 → 重试 5 次（默认 stream_max_retries=5，跟你看到的次数对得上）→ 放弃。

Chat: cache HIT 后立刻 Client disconnected mid-stream 是 症状：codex 客户端先放弃断开 TCP，这边的 realRes 'close' 才把 captureRes 推到 disconnect 分支。所以 cache HIT 是触发条件之一（同步 emit 让坏 envelope 的问题暴露得最干脆），但本质是 envelope 结构不合规范。

提交：0db6d24 — 等下一个 v2.0.7 release 出来跟你的 docker-compose 配合就直接生效。如果你急用可以 git pull 后本地 docker compose up --build 先验。

再试试呢