docs(workbuddy): 「模型不响应」的排障结案 + 可复跑工具 - #68
Open
Siyuan-Zhao770707 wants to merge 1 commit into
Open
Siyuan-Zhao770707 wants to merge 1 commit into
Siyuan-Zhao770707 wants to merge 1 commit into
Conversation
|
ⓘ Qodo reviews are paused because your trial has ended. Ask your workspace admin to add credits to resume reviews. Manage billing |
|
Warning Review limit reachedNext included review available in 59 minutes. View limit detailsLimit details: You’ve used the included review currently available. You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. Review configuration: ⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Advanced Run ID: 📒 Files selected for processing (3)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
… ship the tool that proves it A user reported that the chat model stopped answering once the adapter was active, which points at the injection by default. It was not the injection: the upstream endpoint took 15.7 s to produce a single token on that request (24.2 s for an adjacent background request, against a p50 of 2.6 s over the same day), the user cancelled at ~15 s, and the host then never left its cancelled/streaming state — `.cr-send-button` stayed disabled with the "cancelled" marker up for 25 minutes while the backend had already persisted `status=completed`. Write the evidence chain down, together with the numbers that ruled the adapter out (a forced style recalc costs 0.06 ms with our four sheets injected versus a 4.9 ms baseline; the renderer reported `loop-lag macro=0ms`; every contract anchor matched). The postmortem alone would rot, so add `scripts/wb-latency-report.mjs` (`npm run wb:latency`), which reads the host's own worker logs and reconstructs send -> first token -> complete/cancel with TTFT percentiles. It only reads `~/.workbuddy/logs`, never prints prompt text, and does not touch the page or the injection. Also note the reading rules for next time: a cancel landing before the first token means the user gave up, not that the model broke, and a frozen composer with an idle event loop means host state, not the adapter.
Siyuan-Zhao770707
force-pushed
the
docs/workbuddy-latency-notes
branch
from
September 21, 2026 04:19
b69e638 to
256e2c7
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
背景
用户报：WorkBuddy 适配生效后「对话大模型不响应」。这类报告默认会指向注入层，所以我把逐层取证的过程和结论一并写进
docs/host-adapter-workbuddy.md新增的 §15，并把取证做成可复跑的脚本，免得下次再从 CSS 开始猜。结论：与注入无关
两件事叠加：
POST https://copilot.tencent.com/v2/chat/completions那次请求 15.7 秒没吐一个 token；相邻的后台请求首字延迟 24.2 秒；而当天同一台机器 177 次请求的 p50 是 2.6 秒。用户在 ~15s 按了「停止」。.cr-send-button持续disabled、.cr-cancelled-indicator（「用户已取消」）常驻 25 分钟，而后端日志runtime-status: persisted status=completed, state=idle。两边不一致，于是「发不出消息」比「模型慢」更像故障。量化排除适配层（写在文档里的证据）
[perf] [loop-lag] macro=0ms micro=0ms.teams-container/.conversation-shell/.cr-input-container/.cr-message-list）全部命中，舞台与面板pointer-events:nonewindow.__bcPickRequest=777，150ms 内被取件轮询清成 0（沙箱里ps不可用，这条比ps可靠）[ModelProvider] Sending request: agent=cli, url=…/v2/chat/completions，随后Request failed: … error=canceled新增工具
scripts/wb-latency-report.mjs（npm run wb:latency）：读
~/.workbuddy/logs/<date>/*.log，把send → first token → done / canceled串成时间线并给出 TTFT 分位数。只读日志：不打印 prompt 正文、不碰页面、不改注入。真实输出示例：
判读规则（下次直接照抄）
send与first的间隔 = 上游出字时间；cancelled出现在first之前 = 用户主动放弃，不是模型坏了。loop-lag macro=0ms+ 发送键disabled+ 取消标记常驻 = 宿主前端状态机没恢复（适配层不接管输入区，改不动；重启宿主即恢复）。影响范围
纯文档 + 新增一个只读脚本 + 一条 npm script，不动任何注入逻辑。