 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 |
|
Leo