fix: 補上 SSE error 事件的 message 提取路徑 (#25) - #26
Merged
Conversation
idd-tree-lock.sh 在 acquire 時寫 .claude/.idd/tree-lock 作為 per-machine session state，該檔不應被追蹤。此改動由 tool 自動產生、與任何 issue 的 實作內容正交，故獨立成 commit 不混入變更集。
後端在 HTTP 200 stream 內以 {"type":"error","error":{...,"message":...}}
回報錯誤時，提取鏈三條路徑無一命中，全部落到 fallback "Codex error"，使
200-stream 內的失敗無法區分原因（實測觸發：server_is_overloaded）。
改動：
- 抽出 extractErrorMessage(_:)，補上 json["error"]["message"] 路徑，插在
既有 top-level message 之後以免搶先既有行為
- processEvent 改呼叫該 function（行為等價，差別只在新增的那條路徑）
- 加 hidden flag --selftest-error-extract（不列 --help、不發 HTTP），讓提取
邏輯可被 bats 獨立驗證 —— CODEX_URL 是 hardcoded 常數、無注入點，沒有這個
hook 此 bug 結構上無法自動化回歸，這也是它存活至今的原因
- 新增 test/codex-call-error-extract.bats：5 case，含實測 payload 作為
regression 錨點，以及「新增路徑不得搶先」的順序保護
實測確認 HTTP 4xx 類（model 400 / auth 401）走既有 HTTP 錯誤路徑並正確
報告，不受此 bug 影響，故未改動 line 229-232。
Member
Author
Verify Report — PR #26Enginepai-ensemble 2.20.0 (canonical #207) — 4 IDD lenses + DA + Codex (gpt-5.x), model: opus Reviewers: AggregateFAIL — 5 HIGH, 9 MEDIUM, 13 LOW, 9 INFO（共 36） HIGH findings 中三項經 coordinator 獨立複驗成立（證據見下方「Coordinator 複驗」）。不打 Scope coveragePR refs: #25 · Verified scope: #25 Findings
Coordinator 複驗（三項 HIGH，獨立於 ensemble 重新查證）
第三項有本次 run 的活體證據：codex lens 因配額用盡而失敗，回傳的 finding（#28）正是那句硬編碼字串 —— 新提取出來的 三項 HIGH 對 issue #25 主張的衝擊1. Diagnosis 的一個前提被推翻。 issue 主張「 後果：backend 若先送帶 message 的 2. 修法不完整。 補提取路徑是必要但不充分。latch 是一行、且不牴觸 out-of-scope 宣告（不動 early-return）： case "error", "response.failed":
if streamError == nil {
streamError = NSError(domain: "codex-call", code: -1,
userInfo: [NSLocalizedDescriptionKey: extractErrorMessage(json)])
}3. 使用者可見層級為 no-op。 即使 codex-call 端完全修好，ensemble 報表仍顯示硬編碼字串。要讓 #25 的自陳目的成立， Process Gaps
Scope Check
NextFAIL — 不可 merge。 需修復後重跑 verify：
|
4 tasks
回應 /idd-verify --pr 26 的三項 HIGH（master report: https://github.com/PsychQuant/parallel-ai-agents/pull/26#issuecomment-5134345657）。 1. first-event latch（HIGH，logic lens） 原 diagnosis 主張「didReceive 的 return 讓第一個 error 事件勝出、後續 response.failed 到不了 processEvent」——該推理不成立：那個 return 只離開 當次 callback，未取消 task（invalidateAndCancel 要等 done.wait 回來）。 後續 chunk 仍重入 case 並覆寫 streamError，跨 TCP chunk 時勝出的是最後 一個。尾隨一則 error:null 的 response.failed 會把好訊息覆寫回 "Codex error"，且隨網路分塊非決定性。加 if streamError == nil，與同檔 didCompleteWithError 既有 latch 寫法一致。 2. CI guard（HIGH，requirements + logic lens） codex-call 是 #!/usr/bin/swift script（macOS-only），而 CI 的 shellcheck-bats job 跑 ubuntu-latest + `bats test/` glob 整個目錄。 無 guard 時本檔 4/5 紅燈，且「無效 JSON → 非零 exit」那則會因 exit 126 (bad interpreter) ≠ 0 而以錯誤理由通過——永遠綠、什麼都沒驗到。 setup() 加 Darwin + CLT swift guard。兩側均實測：有 swift 5/5 pass、 模擬無 swift 5/5 skip。 3. version bump（MEDIUM，regression lens） plugin.json + marketplace.json 2.20.0 → 2.20.1，CHANGELOG 補 2.20.1 段。未 bump 則 fix 無法經 /plugin update 抵達使用者。 消費端硬編碼丟棄 codex-call 錯誤輸出（HIGH，devil's-advocate lens）動的是 workflows/ensemble-workflow.js、屬不同抽象層，依使用者裁決拆為獨立 issue #27。 已知未覆蓋：latch 行為本身無自動化測試——它在 StreamCollector 內部，現有 selftest hook 只測純函式 extractErrorMessage，測不到 processEvent 接線。 此缺口與 verify 的 MEDIUM findings 一併待 follow-up triage，不在本次宣稱 已解決之列。
Member
Author
Fix round 1 — 回應 verify FAIL 的三項commit
對 R1 finding #3 的正面承認該 finding 推翻了本 issue diagnosis 的一個前提。原推理是「 latch 修法不動 early-return，因此不牴觸原本的 out-of-scope 宣告 —— 但原宣告所依據的理由是錯的，這點已寫進 commit message 與 CHANGELOG，不掩蓋。 已知未覆蓋（不列入本輪宣稱已解決）latch 行為無自動化測試。 它在 本輪未處理的 R1 findings：9 MEDIUM 中的 8 項、13 LOW 全部。將於 R2 verify 後一併 triage。 |
Member
Author
Verify Report — PR #26 (Round 2)Enginepai-ensemble 2.20.0 (canonical #207) — 4 IDD lenses + DA + Codex (gpt-5.x), model: opus Reviewers: AggregateFAIL — 4 HIGH / 16 MEDIUM / 5 LOW / 9 INFO（共 34） 本輪為 4-AI（4 lens）—— DA 撞 session limit、codex 配額未回補，兩者皆記 fail-closed，不計入 PASS。 Frozen at Findings
R1 修復的成效判定
Latch 的四交錯矩陣（reviewer 以逐字複製的 Swift harness 實測）我的 latch 沒有消除這個失敗類別，只是把它從 D 搬到 B。 換到的是「非決定性 → 決定性」，但 CHANGELOG 宣稱「HTTP 200 stream 內的後端錯誤不再塌成籠統的 "Codex error"」在 B 情境下是假的，而 B 在修法前是好的。 根因： 兩缺陷是複合的（R2-HIGH #3）即使把 latch 換成 informativeness rule，case A 仍然失敗 —— 因為 必須兩者同時改，任一單獨改都不足以覆蓋四種交錯。而終端錯誤正是 backend flush + close 的時刻 —— 兩事件同 chunk 抵達的機率不低於分開。 我在本輪被指出的其他事實錯誤
Process Gaps
NextFAIL — 不可 merge。 正確修法需同時處理 latch policy 與 early-return，而後者原被本 issue 宣告為 out-of-scope —— 該宣告所依據的理由已在 R1 被推翻、其必要性又在 R2 被證明，scope 是否擴大需由 issue owner 裁決。 |
回應 /idd-verify --pr 26 R2 的三項 HIGH（scope 擴大經 issue owner 裁決）。
R2 證明 R1 的 first-wins latch 只是把失敗搬家，不是消除。reviewer 逐字複製
控制流實測四交錯：
R1 latch 後
A 同 chunk, bare→rich → Codex error
B 分 chunk, bare→rich → Codex error ← R1 引入的回歸（修法前是好的）
C 同 chunk, rich→bare → 真實訊息
D 分 chunk, rich→bare → 真實訊息 ← R1 要修的那個
根因：`if streamError == nil` 是到達順序政策，本 issue 需要的是訊息資訊量
政策。兩者只在「先到者必定較有資訊」這個無證據假設下重合。
改動：
1. informativeness 政策取代 first-wins
僅當「手上是 fallback 且新來的不是」時升級；永不讓後到事件降級已持有的
訊息。新增 CODEX_FALLBACK_MESSAGE 常數與 streamErrorIsFallback 狀態。
2. 移除 buffer while-loop 的 early return（scope 擴大，owner 裁決 A）
該 return 在單次 callback 內中止 drain loop，使已在 buffer 的 sibling
終端事件完全不被處理 —— 而終端錯誤正是 backend flush+close 的時刻，同
segment 抵達的機率不低於分開。與第 1 項是複合缺陷：只修其一皆不足以
覆蓋四交錯（R2 實測佐證）。原 issue 曾宣告此項 out-of-scope，其依據的
理由已在 R1 被推翻、必要性又在 R2 被證明。
3. feed(_:) 抽出 + --selftest-process-events hook
把 didReceive 的 drain 邏輯抽成可獨立呼叫的方法，hook 吃 chunk 字串陣列
驅動真實 StreamCollector。chunk 邊界成為可表達的測試輸入，不需網路或
CODEX_URL 注入點。R2 指出我「latch 結構上不可測」的辯護不成立 —— 確實
可測，此處即為實作。
4. test/codex-call-stream-latch.bats（9 case）
四交錯矩陣 + 邊界（僅 bare / 僅 rich / 雙 rich / 無終端事件 / 非陣列）。
RED 先行：實作前 8/9 紅。
5. macos-swift-bats CI job
只加 skip guard 會把 R1 的紅燈換成永遠 skip 的 vacuous green —— repo 只有
ubuntu job，錨點等於零覆蓋。新 job 另含 swift 存在性斷言，避免 guard 在
本該執行的環境靜默 skip。
6. 移除錯誤註解
R1 寫的「Mirrors the existing latch at didCompleteWithError」事實有誤 ——
該處 non-200 branch 是無條件覆寫、並無 latch。我用錯誤類比為修法背書。
7. metadata 一致性
plugin.json description 補 v2.20.1（R1 只改了 version 欄，與 marketplace
不一致）；CHANGELOG 回填從未記錄的 2.19.0 / 2.20.0；test/README 註冊兩支
新檔並註明 macOS-only 與對應 CI job。
未處理：R1/R2 其餘 MEDIUM/LOW（含 extractErrorMessage 回傳未設長度上限、
selftest hook 的 exit-0-without-output 語意），待 verify 通過後一併 triage。
Member
Author
Fix round 2 — scope 擴大（owner 裁決 A），一次修完 latch policy + early-returncommit
四交錯矩陣 —— 現在全綠新增 A 與 B 分別是「只修 drain 不夠」與「只修 policy 不夠」的哨兵 —— 兩項複合缺陷各有一個 case 釘住。 對 R2 的正面承認R2 推翻了我兩件事，都已寫進 commit message 與 CHANGELOG，不掩蓋：
仍未處理R1/R2 其餘 MEDIUM/LOW，含： |
Member
Author
Verify Report — PR #26 (Round 3)Enginepai-ensemble 2.20.0 (canonical #207) — 4 IDD lenses + DA + Codex, model: opus Reviewers: AggregateFAIL — 8 HIGH / 14 MEDIUM / 15 LOW / 9 INFO（共 46） Frozen at Findings
本輪的核心前提又是假的（DA HIGH #1）我在 guard let chunk = String(data: data, encoding: .utf8) else { return } // :246
feed(chunk)URLSession 的
而且這被本 plugin 的預設放大： 我的 「informativeness」只是 1-bit 投影（DA HIGH #2）
而後端 teardown 的真實形狀恰恰落在這格： 更嚴重：我的新測試 case 7「兩個 rich：先到者保留」把這個無證據的偏好從未定義行為升級成有測試保護的契約。下一輪若拿到真實 trace 發現該改，改對的方向會被自己的測試擋下，且看起來像「破壞既有行為」。 DA 同時否定了我在 prompt 裡提出的 desync 假設： 其他 HIGH
三輪的模式
三次都是從局部觀察跳到全域結論，再用一段自信的註解為它背書。 Process Gaps
Next — 建議重新框定 scope，而非再補一輪DA 對「#25 是否仍是一個可交付單元」的回答（LOW #24）值得完整採納：
具體代價在 CHANGELOG 上最清楚：2.20.1 的四條 Fixed 有三條修的是本 PR 自己在 R1 造成的東西，從未出貨給任何使用者，卻被寫成產品修復史。 建議切法（DA 提出，我同意）：
|
三輪 verify（PR #26）各推翻了一個我當時最有把握的前提： R1 diagnosis 的「early-return 讓第一個 error 勝出」 → return 只離開當次 callback，不取消 task R2 R1 的 first-wins latch「消除了問題」 → 實測只是把失敗從 D 搬到 B；連帶推翻「latch 不可測」的辯護 R3 R2 的「chunk 邊界已可測」＋「這是 informativeness 政策」 → feed([String]) 表達不出 byte 邊界；那只是 1-bit 投影， rich↔rich 仍是 arrival-order 共同的根因不是修得不夠細，是 scope 框錯：#25 的原始症狀有可重現的 payload、是 one-line fix；被綁上來的「多個終端事件誰勝出」則至今 沒有人觀察過後端 teardown 的實際行為。證據強度不同的東西綁在同一個 交付單元，於是每一輪都在為沒有證據的部分發明理由。 本 commit 依 R3 devil's-advocate 的建議切分（owner 裁決）： 保留於 #25（三輪 verify 從未推翻過的部分） - extractErrorMessage(_:) 抽出 + json["error"]["message"] 路徑 - --selftest-error-extract hook（讓上述可回歸） - test/codex-call-error-extract.bats 5 case - version bump 2.20.1 + metadata 移交 #28（同一子系統、同一組缺證據的問題） - informativeness 政策與 streamErrorIsFallback（回復無條件賦值） - buffer drain 的 early-return 放寬（回復原狀） - feed(_:) 抽出與 --selftest-process-events（連同 9 case 一併移除） - byte-level 分幀、殘留 buffer flush、CRLF、didCompleteWithError 同址政策 回復處皆留 KNOWN GAP 註解指向 #28，不是靜默還原。 其餘修正： - marketplace.json 與 plugin.json 的 description 曾寫「first-event latch」—— 那是被推翻且已刪除的設計，front-door 文案描述了不存在 的機制，一併清掉並與 plugin.json 對齊 - CHANGELOG 2.20.1 原有四條 Fixed，其中三條修的是本 PR 自己在 R1 造成、從未出貨的東西 —— 寫成產品修復史會讓讀者以為 2.20.0 曾帶著 arrival-order latch 出貨。只保留真正出貨過的那一條，並新增 Known limitations 指向 #28 - macos-swift-bats job 改 glob 檔名並斷言 run 的「輸出」而非 guard 的「輸入」：bats 在全部 skip 時 exit 0，只檢查前提會讓 vacuous green 搬高一層 Refs #28
Member
Author
Scope 收斂 — 分幀與終端事件政策移交 #28commit 為什麼收斂而不是再補一輪三輪 verify 各推翻了一個當時最有把握的前提：
共同根因不是修得不夠細，是 scope 框錯：#25 的原始症狀有可重現 payload、是 one-line fix；被綁上來的「多個終端事件誰勝出」則至今沒有人觀察過後端 teardown 的實際行為。證據強度不同的東西綁在同一個交付單元，於是每輪都在為沒有證據的部分發明理由。 保留於 #25（三輪 verify 從未推翻過）
移交 #28
回復處皆留 一併修掉的 R3 findings
|
7 tasks
回應 /idd-verify --pr 26 R4。最嚴重的一項是我上一輪自己寫進去的。
1. CI step 吞掉 bats 失敗（四個 lens 獨立命中，HIGH）
`bats … | tee /tmp/bats.tap` 的 exit status 是 tee 的（永遠 0）。
GitHub Actions 預設 shell 是 `bash -e {0}` —— 有 errexit、沒有
pipefail —— 所以測試 FAIL 不會讓 step 失敗。兩道 grep 也補不上：
`grep -q '^ok'` 只要有任何一個 sibling 通過就滿足，而 `not ok`
不匹配 `^ok`。
這是回歸：ab1d266 的舊版是 bare command、exit code 正確傳播。我為了
修 vacuous green，做出了更糟的 vacuous green —— 「全部 skip」至少
還會被抓到，「regression 錨點真的壞了」則不會。
修法三重：顯式 `shell: bash`（取得 -eo pipefail）+ 自行 `set -o
pipefail` + 新增 `^not ok` 檢查。實測驗證：植入一個必失敗的 case 後，
修正版 step exit=1、舊版 exit=0。
2. front-door 宣稱過廣 + #27 完全未揭露（HIGH）
marketplace.json / plugin.json 原本無條件宣稱「不再塌成 Codex
error」。這對直接呼叫 codex-call 為真，但每個 first-party consumer
都仍以硬編碼字串回報失敗（#27），所以對用 plugin 的人幾乎是 no-op。
而 Known limitations 詳列了 #28 的四項，卻對 #27 隻字未提 ——
唯一會讓宣稱效益歸零的那個 gap，是唯一沒被揭露的。
兩處 description 改為明確區分「直接呼叫」與「經 ensemble 使用」；
Known limitations 新增 #27 條目並說明為何列出。
3. 三輪 verify 的可執行產物被刪除（HIGH）
收斂時把 codex-call-stream-latch.bats（四交錯矩陣）與
--selftest-process-events 一併刪掉，使 #28 只剩散文、KNOWN GAP
不可稽核。已將 harness 全文、hook 實作、R2 實測矩陣完整保存進 #28
的 comment，並註明該 harness 本身的限制（吃 [String]，表達不出
production 的 byte 邊界）。
4. 其餘
- extractErrorMessage 的 18 行 rationale 因我插入常數而被空行切開、
附著到常數上；移回緊貼 func
- 移除 hook 刪除處殘留的連續空行
- CHANGELOG 與 bats 檔頭原寫「三條路徑」—— 修正前實際只有兩條
Refs #27
Refs #28
回應 /idd-verify --pr 26 R5 的三項 HIGH。本 commit 的每一條宣稱都附修正後的 逐字內容 —— R5 devil's-advocate 指出我前幾輪的根本問題是 self-certification without re-reading（同一個 commit 內兩處「宣稱已修但沒落地」），這是它開的止血方。 1. security HIGH：本 PR 啟用了未設上限、未淨化的後端文字出口 論證成立且我接受：修正前後端實際送的 error.message 塌成常數，這條路徑 實務上是死的；補上提取路徑正是讓它活起來的那個改動，所以 cap 屬於同一個 變更而非 #28 的延後項。同檔另兩處外部文字本來就 .prefix(500)，只有我新建 的這條沒有。 bin/codex-call:246（修正後逐字）： return stripped.count > 500 ? String(stripped.prefix(500)) + "…(truncated)" : stripped 同時剝除 C0/DEL/C1（保留 newline 與 tab）—— 該字串直寫 TTY，且經 Bash tool 進入 agent context；CSI/OSC 可覆蓋真實錯誤。實測：600 字元 → 512 bytes 且帶 截斷標記；ESC/BEL 被剝除而 "safe"/"wiped" 保留；newline/tab 保留；一般長度 訊息逐字不變。新增 4 個 bats case 釘住（5 → 9）。 2. regression HIGH：bats 檔頭的「三條路徑」我上一輪宣稱改了，實際沒改 查證屬實。git show main 確認修正前只有兩條路徑加一個 fallback，而 3506f7c 只改了 CHANGELOG 與測試名稱，檔頭原封不動。 test/codex-call-error-extract.bats:6-7（修正後逐字）： # 時，提取鏈**只有兩條**路徑（top-level message、response.error.message）， # 漏掉 json["error"]["message"]，故兩條皆不命中 → 3. logic MEDIUM：CI 的「三重機制」實際只有一重在工作 errexit + pipefail 下，bats 失敗會讓 step 在任何 grep 執行前就中止，所以 `^not ok` 那句 ::error:: 從不觸發，只會看到通用的 exit code 1。改為捕捉 bats 的 rc、跑完三項檢查再依 rc 收尾；skip 檢查改 -i（bats 未 pin，TAP directive 大小寫是它的選擇）；TAP 路徑改用 $RUNNER_TEMP。 四情境實測（bash -e 模擬 Actions shell）：全過→0；植入失敗→1 + "a codex-call test failed"；全 skip→1 + "vacuous"；glob 空→1 + "no tests ran"。每個情境都印出自己的訊息，不再被 errexit 搶先。 本輪測試撰寫時自己踩到一次：控制字元若以 literal 寫進 JSON payload，會讓 payload 本身成為非法 JSON，於是測到的是解析失敗而非 sanitize 生效。已改用 JSON 規範的 backslash-u 逸出序列表達，並把這個陷阱寫進該 case 的註解。 仍未處理：#27（消費端硬編碼）、#28（分幀與終端事件語意）、以及 R1-R5 其餘 MEDIUM/LOW（含 --selftest-error-extract 靜默壓過 --output）。 Refs #27 Refs #28
…an (#25) CI 實證失敗（非本機可見）：macos-swift-bats job 紅燈 13 秒。 根因（GitHub Actions run 30646773664 的 log 逐字）： 1..9 bats: unknown test name `$'test_-2325_regression-ffffffffffffffef層_error_...' # bats warning: Executed 0 instead of expected 9 tests ##[error]no tests ran (empty glob or bats bail-out) `brew install bats-core` 這版在把 @test 標題轉成 shell 函式名時 mangle CJK code point（`ffffffffffffffef` 是 byte 被當 signed char），於是宣告 1..9 卻執行 0 個。ubuntu job 的 apt bats 沒有這個行為，所以既有 7 支中文標題的 測試在該 job 一直是綠的，本機亦然 —— 這是 brew 版特有的差異。 修法：9 個 @test 標題改 ASCII，中文說明移到各 case 上方的註解（註解不會被 轉成識別字）。本機與 LC_ALL=C 兩種 locale 下皆 9/9 綠。 值得記錄的正面證據：**這次是我加的第三道檢查救的**。若只有 R4 那版（pipe 吞掉 exit code）或只有前兩道檢查，這會是一個「宣稱 9 個測試存在、實際執行 0 個」的完美 vacuous green —— 正是這個 job 存在的理由。gate 不是裝飾。 同時也是「本機綠不等於 CI 綠」的實例：我在本機驗過四個情境（全過 / 植入 失敗 / 全 skip / glob 空）全部正確，但驗不到 brew 版 bats 的 CJK 行為。 Freshness 說明：R6 verify 正在 in-flight，凍結於 aabbb9e。本 commit 使 HEAD 前進，故 R6 的 verdict 描述的是前一個 snapshot。delta 僅為測試標題 字串與註解位置，不觸及 sanitizeBackendText、extractErrorMessage、CI step 邏輯或任何被審的行為 —— 收尾時會在報告中標明此分歧，不當作已審。
回應 /idd-verify --pr 26 R6（codex lens 本輪恢復，6-AI 到齊）。三項實質缺陷，
其中兩項是我上一輪自己引入或宣稱的。
1. 我宣稱的 cap 根本不 cap（4 個 lens + codex 獨立命中）
`stripped.count > 500` 數的是 extended grapheme cluster，長度無上限 ——
一個基底字元加 N 個組合記號是「一個」Character。實測逃逸：
500 個 CJK 字元 → 1,500 bytes 通過，無截斷標記
500 個 ×20 組合記號 → 20,500 bytes 通過，無截斷標記
而本工具預設輸出就是 CJK，所以這不是對抗性情境才發作，是「出現一則中文
錯誤訊息就發作」。
改為 UTF-8 byte（2000）+ 行數（20）雙預算。行數上限是必要的另一半：
reviewer 實測 475 個換行可把真錯誤捲出 TTY 視窗，而 newline 正是我在
doc comment 裡寫「不帶終端控制能力」而刻意保留的字元 —— 那句 rationale
是假的，已改寫成「保留是為了可讀性，其版面能力由行數上限約束」。
2. 新增的「newline / tab 保留」測試是套套邏輯（mutation 實證）
三個子字串斷言對「保留」與「剝除」不可分辨：剝除後的 line1line2end 仍
同時包含 line1、line2、end。reviewer 刪掉保留子句後全套件仍 9/9 綠。
改為斷言分隔符本身：[ "$output" = $'line1\nline2\tend' ]。
我這輪自己也跑了 mutation 驗新測試有分辨力（而非再次宣稱）：
換回 grapheme cap → case 12（組合記號）、case 13（行數）轉紅
移除 newline 保留 → case 8（分隔符）轉紅
測試 9 → 13。
3. CHANGELOG 停留在前一個 commit 的狀態
寫「5 case」而檔案有 13 個 @test；且完全沒記錄 sanitize/cap 這個**使用者
可見的行為改變**（所有後端錯誤訊息自此會被截斷、控制字元會被移除）。已補
`### Changed` 一節說明預算語意與為何不用 Character 計數，並更新 Known
limitations 列出 sanitize 尚未覆蓋的類別（bidi/Tags/FEFF/U+2028-9）與另外
兩個仍用 String.prefix(500) 的 sibling sink，全部歸 #28。
依 R6 devil's-advocate 的裁決收斂：byte cap 現在改對，其餘 sanitize 議題
（bidi、Tags、行數以外的版面問題、sibling 一致性、marker 可偽造、以及
`accumulated` 那條更大的未設防通道）併入 #28 一次處理，不再逐輪片段修補。
Refs #28
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.
Refs #25
Summary
bin/codex-call在後端於 HTTP 200 stream 內以 SSEerror事件回報錯誤時，訊息提取鏈漏了json["error"]["message"]這條路徑，三條路徑無一命中 → 全部落到 fallback"Codex error"，使 200-stream 內的失敗無法區分原因。實測觸發：
server_is_overloaded（ChatGPT 後端壅塞）。實測同時確認 HTTP 4xx 類（model 400 / auth 401）走既有 HTTP 錯誤路徑並正確報告，不受影響 —— 故 issue 的 Impact 範圍在 diagnose 階段已據實下修。Changes
extractErrorMessage(_:)，補上缺漏路徑（插在 top-level message 之後，不搶先既有行為）processEvent改呼叫該 function--selftest-error-extract（不列--help、不發 HTTP）——CODEX_URL是 hardcoded 常數無注入點，沒有這個 hook 該邏輯結構上無法自動化回歸test/codex-call-error-extract.bats5 case，含實測 payload 作 regression 錨點與順序保護chorecommit（.gitignore加 tree-lock state）刻意不帶 issue ref —— IDD 工具自動產生，與本 issue 正交。Checklist
Generated by /idd-implement on PR path. Do NOT add a GitHub close trailer — IDD discipline requires manual /idd-close after merge to enforce checklist gate + closing summary.