身為 Arcrun 使用者，我要工作流裡的「等一下」不吃我的運算額度 #101

New Issue

2026-08-12T06:32:53Z

Leo commented

2026-08-12 06:32:53 +00:00

身為 Arcrun 的使用者，我要工作流裡的「等一下」不吃我的運算額度，我才能放心在流程裡等外部系統跟上。

現在會怎樣

一個只做等待、什麼事都不做的工作流，會把 Worker 的 CPU 燒到上限然後 503。

實測（youlin stage，只有 input >> wait 兩個節點）：

ms=3000        → 38.9 秒後 503（error code 1102 資源超限）
ms=20000       → 34.0 秒後 503
ms=30000       → 34.9 秒後 503
ms 寫死 3000   → 34.8 秒後 503     ← 排除「值沒傳進去」

真實災情：Leo/arcrun-rag#82——出貨管線等 CDN 收斂那一站，
duration_ms: 35534 後死於 Worker exceeded CPU time limit，
後面兩站（驗收、發佈紀錄）一步都沒跑。而東西其實早就送到了。

根因：等待發生在 WASM 裡

registry/components/wait/main.go 第 2 行的註解自己就寫著：

// 注意：TinyGo/WASM 環境中 time.Sleep 可能不可用，改用 busy-wait 模擬
...
time.Sleep(time.Duration(ms) * time.Millisecond)

註解說 busy-wait、程式碼用 time.Sleep——但在 WASM 裡兩者是同一件事：
那顆零件跑在 Worker 的請求執行緒上，它睡多久，Worker 的 CPU 時間就被記多久。

⇒ 等待時間 1:1 換成 CPU 時間。 零件上限寫死 30 秒，而 Worker 的 CPU 預算也是那個數量級
⇒ 等 20 秒＋其他節點就爆。

🔴 所以這不是「那顆零件寫壞了」，是「等待這件事不該發生在 WASM 裡」。
引擎那一側用 JS 等（await 一個 timer）成本接近 0，而且本來就有 async。

要達成什麼

等 30 秒跟等 3 秒，對運算額度的成本應該一樣（接近 0）。

怎麼驗才算數

一個只做 wait 的工作流，ms 從 3000 到 30000 各跑一次，全部成功，貼執行紀錄
同一支工作流在免費層實例上也跑得過（免費層 CPU 預算更小，那才是真正的門檻）
貼修前修後的對照

紅線

不准把等待上限調小來閃過——那是把「等外部系統跟上」這個能力換掉
不准要使用者改用別的節點自己兜——他不該知道 WASM 和 CPU 額度存在
動之前確認：這顆零件退場之後，既有工作流裡的 wait 節點要照樣能跑（不能要人改定義）

相關

Leo/arcrun-rag#82（出貨線的災情現場）｜Leo/arcrun-rag#47（被它卡住：出貨完版控裡沒有這一版）

**身為 Arcrun 的使用者，我要工作流裡的「等一下」不吃我的運算額度，我才能放心在流程裡等外部系統跟上。** ## 現在會怎樣一個**只做等待、什麼事都不做**的工作流，會把 Worker 的 CPU 燒到上限然後 503。實測（youlin stage，只有 `input >> wait` 兩個節點）： ``` ms=3000 → 38.9 秒後 503（error code 1102 資源超限） ms=20000 → 34.0 秒後 503 ms=30000 → 34.9 秒後 503 ms 寫死 3000 → 34.8 秒後 503 ← 排除「值沒傳進去」 ``` 真實災情：`Leo/arcrun-rag#82`——出貨管線等 CDN 收斂那一站， `duration_ms: 35534` 後死於 `Worker exceeded CPU time limit`， **後面兩站（驗收、發佈紀錄）一步都沒跑**。而東西其實早就送到了。 ## 根因：等待發生在 WASM 裡 `registry/components/wait/main.go` 第 2 行的註解自己就寫著： ```go // 注意：TinyGo/WASM 環境中 time.Sleep 可能不可用，改用 busy-wait 模擬 ... time.Sleep(time.Duration(ms) * time.Millisecond) ``` 註解說 busy-wait、程式碼用 `time.Sleep`——**但在 WASM 裡兩者是同一件事**：那顆零件跑在 Worker 的請求執行緒上，**它睡多久，Worker 的 CPU 時間就被記多久**。 ⇒ **等待時間 1:1 換成 CPU 時間。** 零件上限寫死 30 秒，而 Worker 的 CPU 預算也是那個數量級 ⇒ 等 20 秒＋其他節點就爆。 🔴 **所以這不是「那顆零件寫壞了」，是「等待這件事不該發生在 WASM 裡」。** 引擎那一側用 JS 等（`await` 一個 timer）成本接近 0，而且本來就有 async。 ## 要達成什麼 **等 30 秒跟等 3 秒，對運算額度的成本應該一樣（接近 0）。** ## 怎麼驗才算數 1. 一個只做 `wait` 的工作流，`ms` 從 3000 到 30000 各跑一次，**全部成功**，貼執行紀錄 2. 同一支工作流在**免費層**實例上也跑得過（免費層 CPU 預算更小，那才是真正的門檻） 3. 貼修前修後的對照 ## 紅線 - **不准把等待上限調小來閃過**——那是把「等外部系統跟上」這個能力換掉 - 不准要使用者改用別的節點自己兜——他不該知道 WASM 和 CPU 額度存在 - 動之前確認：**這顆零件退場之後，既有工作流裡的 `wait` 節點要照樣能跑**（不能要人改定義） ## 相關 `Leo/arcrun-rag#82`（出貨線的災情現場）｜`Leo/arcrun-rag#47`（被它卡住：出貨完版控裡沒有這一版）

Leo referenced this issue

2026-08-12 07:15:28 +00:00

#101 等待搬回引擎——WASI 沙箱裡沒有「不花 CPU 地等」這種東西 #103

Leo referenced this issue from a commit

2026-08-12 07:26:02 +00:00

Merge pull request '#101 等待搬回引擎——WASI 沙箱裡沒有「不花 CPU 地等」這種東西' (#103) from fix/wait-not-in-wasm-101 into main

Leo referenced this issue from a commit

2026-08-12 07:30:41 +00:00

chore(builds): 重編執行檔——把 wait 的修法真的放進引擎成品（Arcrun#93 的閘抓到的）

Sign in to join this conversation.