Command code GOAT used via API: MiMo V2.6 Pro stream consistently fails at ~785s with
还没有人认领这个 Issue。
评估
- 难度
- 4/5
- 预计耗时
- 3-5 天
- 新手友好度
- 35/100
- Issue 类型
- 缺陷
- 描述清晰度
- 基本清楚
- 活跃度
- 活跃
- 领域
- api, backend, observability
调研方向
Start by inspecting CommandCode trace b416c51c0eb32fde7cd20646bfd99625 and the Provider API route for the xiaomi/mimo-v2.6-pro request. Compare the 785.097-second termination with the gateway_stream_timeout and the COMPLETED record in CommandCode Studio. Done means identifying the timeout source and determining whether the failure status and upstream handling need correction.
由索引模型根据 Issue 内容生成。
描述
Summary
I am using the CommandCode GOAT API through OpenCode in Zed. Long-running autonomous agent sessions occasionally fail when an individual xiaomi/mimo-v2.6-pro inference runs for approximately 13 minutes.
The latest failure produced:
Internal error: {"code":"gateway_stream_timeout","message":"Stream exceeded maximum duration before function timeout","origin":"gateway"}: {
"service": "session",
"errorName": "UnknownError"
}
The corresponding request in CommandCode Studio is:
Model: xiaomi/mimo-v2.6-pro
Duration: 785.097s
Input tokens: 0
Output tokens: 0
Cost: $0.0000
Status: COMPLETED
Trace ID: b416c51c0eb32fde7cd20646bfd99625
Dashboard timestamp: Sep 27, 2:54:10 PM (as displayed in Studio).
Expected Behavior
Continue streaming without ~13 minutes timeouts.
Actual Behavior
"Stream exceeded maximum duration before function timeout"
Steps to reproduce the issue
- Configure OpenCode in Zed to use the CommandCode API (Provider API?).
- Select
xiaomi/mimo-v2.6-pro. - Run a long autonomous coding-agent session. ZDR is not enabled.
- When an individual MiMo inference runs for approximately 13 minutes, the request terminates with:
Internal error: {"code":"gateway_stream_timeout","message":"Stream exceeded maximum duration before function timeout","origin":"gateway"}: {
"service": "session",
"errorName": "UnknownError"
}
- In CommandCode Studio, the corresponding request is recorded as:
Model: xiaomi/mimo-v2.6-pro
Duration: 785.097s
Input tokens: 0
Output tokens: 0
Cost: $0.0000
Status: COMPLETED
Trace ID: b416c51c0eb32fde7cd20646bfd99625
Other MiMo requests in the same session completed successfully, including requests lasting approximately 545s, 399s, and 317s.
The overall agent session was about 32m25s long. The failure appears tied to the duration of one individual streaming inference, not the total session duration.
Command Code Version
N/A
Operating System
Linux
Terminal/IDE
Zed + OpenCode via ACP
Shell
N/A — issue occurs through Zed/OpenCode
Session file (optional)
Not attached. The relevant CommandCode trace is:
b416c51c0eb32fde7cd20646bfd99625
Fix prompt (optional)
Please inspect trace b416c51c0eb32fde7cd20646bfd99625 and determine which gateway or upstream generated the timeout.
The request terminates at 785.097 seconds with:
gateway_stream_timeout
Stream exceeded maximum duration before function timeout
Please check whether the MiMo V2.6 Pro Provider API route has an approximately 785-second maximum streaming duration.
If this limit is imposed by an upstream gateway, please consider routing long MiMo requests through an upstream without this limit, or implementing transparent retry/failover.
Also check why CommandCode Studio records this timed-out request as COMPLETED with 0 input tokens, 0 output tokens, and $0 cost instead of marking it as failed.
Additional context
This has happened several times during one day on the same account - though only this one occurrence is captured.
The timing looks suspicious:
There is a recent Vercel AI Gateway report describing streaming requests being terminated at approximately 785–790 seconds with the same:
gateway_stream_timeout
Stream exceeded maximum duration before function timeout
https://community.vercel.com/t/ai-gateway-streaming-requests-terminate-at-785-790s-despite-a-1800s-function-duration/48725
I don't know whether this CommandCode route uses Vercel AI Gateway or whether this is an equivalent timeout elsewhere in the routing stack, but the timing and error payload appear nearly identical.
- 主要语言
- 没有语言数据
- 星标
- 4k
- 派生
- 357
- PR 合并指标
- 30 天内没有已合并 PR
环境准备
这个项目没有提供开发容器、Dockerfile 或贡献指南，环境需要你自己搭建：先看它的 README，通用步骤见我们的新手贡献指南。
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
CommandCodeAI/command-code 的其他 Issue
-
难度 2/5 1-3 小时 新手友好度 68/100
CommandCodeAI/command-code#933 ·
-
难度 2/5 1-3 小时 新手友好度 68/100
CommandCodeAI/command-code#855 ·
-
难度 2/5 1-3 小时 新手友好度 78/100
CommandCodeAI/command-code#841 · 1 条评论 ·
-
难度 2/5 1-3 小时 新手友好度 68/100
CommandCodeAI/command-code#655 · 1 条评论 ·
-
难度 2/5 1-3 小时 新手友好度 68/100
CommandCodeAI/command-code#608 ·
查看 CommandCodeAI/command-code 的全部 Issue
相似的 Issue
-
难度 2/5 1-3 小时 新手友好度 65/100
openfoodfacts/score-my-recipe#80 ·
维护者通常 2 天内回复
-
难度 2/5 1-3 小时 新手友好度 88/100
snapshot-labs/stamp#702 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 86/100
-
Cainophile EXIT handler crashes on its own password redaction and logs the DB password in clear text未关闭
难度 2/5 1-3 小时 新手友好度 78/100
维护者通常 2 天内回复
-
难度 2/5 1-3 小时 新手友好度 88/100
digitallyinduced/ihp#2832 ·
维护者通常 1 天内回复