A stalled reply says it is asking again while Escape only goes Home
维护者通常 1 天内回复
还没有人认领这个 Issue。
评估
- 难度
- 4/5
- 预计耗时
- 3-5 天
- 新手友好度
- 68/100
- Issue 类型
- 缺陷
- 描述清晰度
- 基本清楚
- 活跃度
- 活跃
- 领域
- cli, testing-qa
调研方向
Start with internal/session/loop.go:2694 and :2471, then inspect internal/tui3/failurerow.go:56 to trace both retry notices and Escape handling. Reproduce through codeaf chat in tmux with the provided stub.py, then add the requested unit and e2e coverage so the displayed promise and request state match Escape's actual effect; update the retry manual and invalidates.
由索引模型根据 Issue 内容生成。
描述
Found on santos/dev2 at 008363c98 (#1410). It reaches dev when #1410 merges.
What happened
On a mid-reply stall, the person saw the model went quiet mid-reply — asking again. The documented wait line no answer N in T · still asking · esc stops was never drawn for that shape. In a conversation, Escape went Home while the re-ask continued in the background. The re-ask behavior is new relative to dev, whose corresponding hand test gave up after two attempts.
Replication
Deterministic (no model). A stub provider that sends one content chunk and then holds the connection open. Save it as stub.py:
# stub.py: a provider whose every reply is one content chunk.
# python3 stub.py cut -> then the connection closes (no finish_reason, no [DONE])
# python3 stub.py hold -> then the connection stays open for ten minutes
import json, sys, time
from http.server import ThreadingHTTPServer, BaseHTTPRequestHandler
MODE = sys.argv[1]
MODEL = "deepseek/deepseek-v4-flash"
class H(BaseHTTPRequestHandler):
protocol_version = "HTTP/1.1"
def log_message(self, *a): pass
def do_GET(self): # the model listing
b = json.dumps({"object": "list", "data": [{"id": MODEL, "object": "model"}]}).encode()
self.send_response(200); self.send_header("Content-Type", "application/json")
self.send_header("Content-Length", str(len(b))); self.end_headers(); self.wfile.write(b)
def do_POST(self):
self.rfile.read(int(self.headers.get("Content-Length", "0")))
self.send_response(200); self.send_header("Content-Type", "text/event-stream")
self.send_header("Connection", "close"); self.end_headers()
chunk = {"id": "c", "object": "chat.completion.chunk", "model": MODEL,
"choices": [{"index": 0, "delta": {"content": "Partial ans"}, "finish_reason": None}]}
self.wfile.write(("data: " + json.dumps(chunk) + "\n\n").encode()); self.wfile.flush()
if MODE == "hold": time.sleep(600)
self.close_connection = True
srv = ThreadingHTTPServer(("", 0), H)
print("http://0.0.0.0:%d/v1" % srv.server_address[1], flush=True)
srv.serve_forever()
export CODEAF_HOME=$(mktemp -d) HOME=$(mktemp -d) OPENROUTER_API_KEY=<any non-empty value>
U=$(mktemp); python3 stub.py hold > "$U" & sleep 1
R=$(mktemp -d) && git -C "$R" init -q && cd "$R"
CODEAF_BASE_URL="$(cat "$U")" codeaf chat --no-host
Send reply with the word OK and wait about a minute. Today the row reads the model went quiet mid-reply — asking again and the request is sent again roughly every 47 s; no answer … still asking · esc stops is never drawn. Press esc: Home opens and the stub keeps receiving requests.
Field (real models). A real provider stall does the same, but it cannot be summoned; the stub is the replication.
Where
internal/session/loop.go:2694 emits the quiet-mid-reply notice; :2471 formats the distinct no answer … esc stops line. internal/tui3/failurerow.go:56 draws the retry event.
The fix
Make the visible escape promise match the actual key behavior on every retry shape. If Escape is meant to stop this wait, route it to the active request before navigating Home; otherwise remove esc stops from the wait line and document background continuation.
Acceptance
- e2e: through
codeaf chatin tmux against a stalled stub, the displayed line accurately predicts Escape's effect, and the request state follows that effect. - Unit: tests cover both notice strings and the active-turn Escape route.
- Update the retry manual and
invalidates.
- 主要语言
- Go
- 星标
- 115
- 派生
- 14
- 平均合并
- 9 小时 38 分钟
- 30 天内合并 PR
- 749
环境准备
我们还没有检查这个项目的环境配置文件。先看它的 README,通用步骤见我们的新手贡献指南。
从这里开始
- 先读完整个 Issue,再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库,在一个分支上完成修改。
- 提交 Pull Request,并在描述里引用这个 Issue 编号。
Agent-Field/CodeAF 的其他 Issue
-
area:chat feature
难度 2/5 1-3 小时 新手友好度 88/100
Agent-Field/CodeAF#1510 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 82/100
Agent-Field/CodeAF#1489 ·
维护者通常 1 天内回复
-
area:chat bug good first issue sev:papercut
难度 2/5 1-3 小时 新手友好度 78/100
Agent-Field/CodeAF#1470 ·
维护者通常 1 天内回复
-
area:chat bug good first issue sev:papercut
难度 2/5 1-3 小时 新手友好度 85/100
Agent-Field/CodeAF#1469 ·
维护者通常 1 天内回复
-
area:chat bug sev:papercut
难度 2/5 1-3 小时 新手友好度 88/100
Agent-Field/CodeAF#1468 ·
维护者通常 1 天内回复
查看 Agent-Field/CodeAF 的全部 Issue
相似的 Issue
-
enhancement low priority
难度 2/5 1-3 小时 新手友好度 85/100
eugenioenko/ttt#674 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 72/100
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 84/100
维护者通常 1 天内回复
-
难度 1/5 1 小时以内 新手友好度 92/100
GoogleCloudPlatform/k8s-config-connector#13462 ·
维护者通常 1 天内回复
-
bug good first issue
难度 2/5 1-3 小时 新手友好度 85/100
vavallee/bindery#2793 · 1 条评论 ·
维护者通常 1 天内回复