[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]

Merged and completed the streaming event sequence. The Responses API path now emits response.completed for both stop and tool_calls, surfaces upstream errors as event:error, and no longer leaves the SSE stream hanging.

[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 先验。

再试试呢

[dwgx]

v2.0.7 updated the /v1/responses compatibility path:

• 0db6d24 wraps lifecycle events in the expected OpenAI-style response envelope, adds monotonically increasing sequence numbers, and emits response.in_progress
• 9e575aa completes the event sequence and avoids leaving clients waiting for a terminal event

The responses stream was validated on a test server after the patch.

[sandleft]

{"error":{"message":"Unsupported Responses tool type: custom","type":"invalid_request_error"}}
API Error: 400 {"type":"error","error":{"type":"invalid_request_error","message":"Tool definitions are too large (214KB > 47KB). Reduce the number of tools or shorten parameter schemas."}}
上面两个来回报错，怎么修都不行，我直接摆烂让gpt跑通了，刚给你提了个pr