回應太大就說「回應太大」——不再冒充「請求失敗」（Arcrun#92） #104

Open

Leo wants to merge 1 commits from fix/error-message-truth-92 into main

Author	SHA1	Message	Date
uncle6me-web	8e9bd09072	fix(engine): 回應太大就說「回應太大」——不再冒充「請求失敗」（Arcrun#92）真因：零件（main.go）給 host function 的接收緩衝區是固定大小（http_request 64KB、 claude_api 1MB）。回應超過這個大小時，wasi-shim 的 writeOut 照寫不誤： new Uint8Array(buf, outPtr, data.length).set(data) data 比零件的 outBuf 大 → 覆寫零件堆積體，零件接著 outBuf[:outLen] 切片 panic；或 writeOut 撞 memory 邊界丟例外 → 回 1 → 零件印一句 "HTTP request failed"。使用者照那句去查連線／URL／防火牆，方向全錯。修法（容量握手，不改 host function 簽名、向後相容）： - 零件呼叫前把 outBuf 長度預先寫進 outLenPtr（宣告容量） - host 在寫回前讀這個值當上限；塞不下就不寫*（不再覆寫零件記憶體），回新的 HOST_TOO_LARGE=3 - http_request host fn 收到 3 → 改寫一段講真話的 error envelope（實際大小＋上限＋「不是連線失敗」＋分頁/篩選的具體做法＋機器可讀 code/actual_bytes/limit_bytes），沿用既有 parsed["error"] 判定鏈原樣送到使用者面前 - 舊零件沒宣告容量（讀到 0）→ 維持舊行為。不可硬套 64KB 預設：各零件緩衝區大小不同，硬套會把原本正常的大回應誤判成「太大」，那只是換一種說謊同一條路徑上另一個「訊息與真因脫節」一併修：component-loader 的 makeHttpRunner `try res.json() catch res.text()`，在零件回非 JSON 時 body 已被消費 → 丟 "Body has already been used"，與真因無關（同檔 readBodyOnce 的註解早就寫明這個坑）。改成只讀一次。驗證狀態（誠實標示，mindset §7）： - 通：5 顆零件 tinygo build 全過，wasm 已重編進 .component-builds/ （claude_api 依 .gitignore 慣例不入庫，由部署端重編） - 未跑：runtime 驗證。本 session 的權限層擋掉 node/vitest/wasmtime， before/after 實測輸出待人跑 scripts/repro-oversize-response.mjs - 未做：.worker-builds/ 重編（需 node scripts/build-worker-artifacts.mjs），否則修法不會進 self-hosted 安裝路徑（Arcrun#93 同款陷阱） Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-12 16:49:22 +08:00

Author

SHA1

Message

Date

uncle6me-web

8e9bd09072

fix(engine): 回應太大就說「回應太大」——不再冒充「請求失敗」（Arcrun#92）

真因：零件（main.go）給 host function 的接收緩衝區是固定大小（http_request 64KB、
claude_api 1MB）。回應超過這個大小時，wasi-shim 的 writeOut 照寫不誤：

    new Uint8Array(buf, outPtr, data.length).set(data)

data 比零件的 outBuf 大 → 覆寫零件堆積體，零件接著 outBuf[:outLen] 切片 panic；
或 writeOut 撞 memory 邊界丟例外 → 回 1 → 零件印一句 "HTTP request failed"。
使用者照那句去查連線／URL／防火牆，方向全錯。

修法（容量握手，不改 host function 簽名、向後相容）：
- 零件呼叫前把 outBuf 長度預先寫進 *outLenPtr（宣告容量）
- host 在寫回前讀這個值當上限；塞不下就**不寫**（不再覆寫零件記憶體），回新的
  HOST_TOO_LARGE=3
- http_request host fn 收到 3 → 改寫一段講真話的 error envelope（實際大小＋上限＋
  「不是連線失敗」＋分頁/篩選的具體做法＋機器可讀 code/actual_bytes/limit_bytes），
  沿用既有 parsed["error"] 判定鏈原樣送到使用者面前
- 舊零件沒宣告容量（讀到 0）→ 維持舊行為。不可硬套 64KB 預設：各零件緩衝區大小不同，
  硬套會把原本正常的大回應誤判成「太大」，那只是換一種說謊

同一條路徑上另一個「訊息與真因脫節」一併修：component-loader 的 makeHttpRunner
`try res.json() catch res.text()`，在零件回非 JSON 時 body 已被消費 → 丟
"Body has already been used"，與真因無關（同檔 readBodyOnce 的註解早就寫明這個坑）。
改成只讀一次。

驗證狀態（誠實標示，mindset §7）：
- 通：5 顆零件 tinygo build 全過，wasm 已重編進 .component-builds/
  （claude_api 依 .gitignore 慣例不入庫，由部署端重編）
- 未跑：runtime 驗證。本 session 的權限層擋掉 node/vitest/wasmtime，
  before/after 實測輸出待人跑 scripts/repro-oversize-response.mjs
- 未做：.worker-builds/ 重編（需 node scripts/build-worker-artifacts.mjs），
  否則修法不會進 self-hosted 安裝路徑（Arcrun#93 同款陷阱）

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

2026-08-12 16:49:22 +08:00

回應太大就說「回應太大」——不再冒充「請求失敗」（Arcrun#92） #104

1 Commits