1042 診斷：workflow http_request 打同帳號 workers.dev 被擋——零件 worker 缺 global_fetch_strictly_public＋一個未解謎 #38

New Issue

2026-07-08T13:37:47Z

Leo commented

2026-07-08 13:37:47 +00:00

背景：arcrun-rag T5-graph（Leo/arcrun-rag#1）的 graph workflows 部署到 leo21c namespace leo 後，/q 驗收撞 CF 1042（http_request fetch arcrun-kbdb.leo21c.workers.dev 回 404 body error code: 1042）。

已確認的硬事實（總管 2026-07-08，CF API 查證）

live arcrun-cypher-executor 有 compatibility_flags: ['nodejs_compat','global_fetch_strictly_public']（executor 舊部署假設排除）。
arcrun-http-request 只有 ['nodejs_compat']、arcrun-code 是 []——零件 worker 沒帶 flag。
wasi-shim.ts:349-362 顯示 http_request 也是 executor 的 host function——所以真正發 fetch 的到底是誰（executor host fn？零件 worker？）需要框架側釐清，這決定 flag 該補在哪。
registry/examples/graph-neighbors/workflow.yaml 檔內宣稱「有 flag 之後 workers.dev URL 亦可直接帶」——與現象矛盾，若查明 flag 不涵蓋同帳號 workers.dev fetch，此註解要修（別讓下個抄範例的人再撞）。

未解謎（物證已滅失，誠實記錄）

07-07 部署在 leo:wf:graph_neighbors 的舊示範 record，2026-07-08 20:10 左右同參數（kbdb_base=https://arcrun-kbdb.leo21c.workers.dev）真的回了正確資料（3 鄰居，與 plugin 一致）；總管重推新 record 覆蓋後同 URL 變 1042。兩份 yaml 的 fetch 行看起來相同。舊 record 已被覆蓋、KV 無版本史，無法比對。可能方向：舊 record 的執行路徑/零件解析與新 record 不同？

請框架側

釐清 http_request 的實際執行體與 fetch 出口。
若缺 flag：零件 worker 的部署配置補 global_fetch_strictly_public 並上游化（別手工 patch，會被下次 update 清掉——同 #32 掉 binding 家族）。
若 flag 不涵蓋 workers.dev：修範例註解＋給 self-hosted 無 custom domain 的正解（cypher binding？kbdb 零件？）。
順帶：acr whoami 顯示的「CF 帳號」與 ~/.arcrun/config.yaml 的 cloudflare_account_id 不一致（顯示 58309b、config 51a01bfa），疑似讀 wrangler 登入態——顯示層 bug，差點造成紅線誤判。

驗收基準（修好後跑）：Leo/arcrun-rag#1 裡的兩條 curl，期望 neighbors 3 筆/traverse nodeCount 5。

[總管]

背景：arcrun-rag T5-graph（`Leo/arcrun-rag#1`）的 graph workflows 部署到 leo21c namespace `leo` 後，`/q` 驗收撞 CF 1042（http_request fetch `arcrun-kbdb.leo21c.workers.dev` 回 404 body `error code: 1042`）。 ## 已確認的硬事實（總管 2026-07-08，CF API 查證） 1. live `arcrun-cypher-executor` **有** `compatibility_flags: ['nodejs_compat','global_fetch_strictly_public']`（executor 舊部署假設排除）。 2. `arcrun-http-request` 只有 `['nodejs_compat']`、`arcrun-code` 是 `[]`——**零件 worker 沒帶 flag**。 3. `wasi-shim.ts:349-362` 顯示 http_request 也是 executor 的 host function——所以真正發 fetch 的到底是誰（executor host fn？零件 worker？）需要框架側釐清，這決定 flag 該補在哪。 4. `registry/examples/graph-neighbors/workflow.yaml` 檔內宣稱「有 flag 之後 workers.dev URL 亦可直接帶」——與現象矛盾，若查明 flag 不涵蓋同帳號 workers.dev fetch，此註解要修（別讓下個抄範例的人再撞）。 ## 未解謎（物證已滅失，誠實記錄） 07-07 部署在 `leo:wf:graph_neighbors` 的舊示範 record，2026-07-08 20:10 左右同參數（`kbdb_base=https://arcrun-kbdb.leo21c.workers.dev`）**真的回了正確資料**（3 鄰居，與 plugin 一致）；總管重推新 record 覆蓋後同 URL 變 1042。兩份 yaml 的 fetch 行看起來相同。舊 record 已被覆蓋、KV 無版本史，無法比對。可能方向：舊 record 的執行路徑/零件解析與新 record 不同？ ## 請框架側 1. 釐清 http_request 的實際執行體與 fetch 出口。 2. 若缺 flag：零件 worker 的部署配置補 `global_fetch_strictly_public` 並上游化（別手工 patch，會被下次 update 清掉——同 #32 掉 binding 家族）。 3. 若 flag 不涵蓋 workers.dev：修範例註解＋給 self-hosted 無 custom domain 的正解（cypher binding？kbdb 零件？）。 4. 順帶：`acr whoami` 顯示的「CF 帳號」與 `~/.arcrun/config.yaml` 的 `cloudflare_account_id` 不一致（顯示 58309b、config 51a01bfa），疑似讀 wrangler 登入態——顯示層 bug，差點造成紅線誤判。驗收基準（修好後跑）：`Leo/arcrun-rag#1` 裡的兩條 curl，期望 neighbors 3 筆/traverse nodeCount 5。 [總管]

Leo commented

2026-07-08 14:08:32 +00:00

更正本 issue 第 4 點：acr whoami 顯示 58309b 不是顯示層 bug——是本機 matrix/arcrun/.env 有一行 CLOUDFLARE_ACCOUNT_ID=58309b…（官方帳號），而 config 優先序 env > 全域 config，whoami 忠實顯示了生效值。CLI 無罪，銷掉這一項。

附帶教訓（差點踩紅線）：在 arcrun repo 目錄內跑任何 acr 部署類命令都會吃到這個官方帳號覆蓋（2026-07-08 acr update 因 token 對不上官方帳號而 Authentication error——這次失敗是紅線自救）。部署 leo21c 的正確姿勢：離開該目錄跑、或明示 CLOUDFLARE_ACCOUNT_ID=51a01bfa…。

[總管]

更正本 issue 第 4 點：`acr whoami` 顯示 58309b **不是顯示層 bug**——是本機 `matrix/arcrun/.env` 有一行 `CLOUDFLARE_ACCOUNT_ID=58309b…`（官方帳號），而 config 優先序 env > 全域 config，whoami 忠實顯示了生效值。CLI 無罪，銷掉這一項。附帶教訓（差點踩紅線）：在 arcrun repo 目錄內跑任何 `acr` 部署類命令都會吃到這個官方帳號覆蓋（2026-07-08 `acr update` 因 token 對不上官方帳號而 Authentication error——**這次失敗是紅線自救**）。部署 leo21c 的正確姿勢：離開該目錄跑、或明示 `CLOUDFLARE_ACCOUNT_ID=51a01bfa…`。 [總管]

Leo commented

2026-07-31 10:22:13 +00:00

08-01 複核：✅ 主因已修復，關閉

本 issue 的可行動主因（硬事實第 2 點：零件 worker 沒帶 flag）已解：

$ git show gitea/main:.component-builds/http_request/wrangler.toml | grep compatibility_flags
compatibility_flags = ["nodejs_compat", "global_fetch_strictly_public"]

落地 commit 1e85dfb（同 #33，已一併關閉）。修在版控部署配置、非手工 patch ⇒ 不會被下次 update 清掉。

逐條回應原請求：

~~釐清 http_request 實際執行體與 fetch 出口~~ → 由「補 flag 後 1042 消失」反證發 fetch 的確實是零件 worker 本身。
✅ 補 flag 並上游化——已完成。
flag 涵蓋同帳號 workers.dev fetch ⇒ 範例註解（graph-neighbors/workflow.yaml 宣稱「有 flag 之後 workers.dev URL 亦可直接帶」）與現況一致，不需修。
acr whoami 顯示 CF 帳號與 ~/.arcrun/config.yaml 不一致（顯示 58309b／config 51a01bfa）——這條是獨立的顯示層 bug，未隨本案修。它差點造成紅線誤判，值得留著；但綁在這張 1042 診斷票上會被埋沒 ⇒ 建議需要時另開專票追。

未解謎（07-08 舊 record 同參數曾回正確資料）：物證已滅失（KV 無版本史），且 flag 補上後現象不再出現，無法也不必再追。誠實記錄於此，不擋關閉。

## 08-01 複核：✅ 主因已修復，關閉 **本 issue 的可行動主因（硬事實第 2 點：零件 worker 沒帶 flag）已解**： ``` $ git show gitea/main:.component-builds/http_request/wrangler.toml | grep compatibility_flags compatibility_flags = ["nodejs_compat", "global_fetch_strictly_public"] ``` 落地 commit `1e85dfb`（同 #33，已一併關閉）。修在版控部署配置、非手工 patch ⇒ 不會被下次 update 清掉。 **逐條回應原請求**： 1. ~~釐清 http_request 實際執行體與 fetch 出口~~ → 由「補 flag 後 1042 消失」反證發 fetch 的確實是零件 worker 本身。 2. ✅ 補 flag 並上游化——已完成。 3. flag 涵蓋同帳號 workers.dev fetch ⇒ 範例註解（`graph-neighbors/workflow.yaml` 宣稱「有 flag 之後 workers.dev URL 亦可直接帶」）**與現況一致，不需修**。 4. `acr whoami` 顯示 CF 帳號與 `~/.arcrun/config.yaml` 不一致（顯示 58309b／config 51a01bfa）——**這條是獨立的顯示層 bug，未隨本案修**。它差點造成紅線誤判，值得留著；但綁在這張 1042 診斷票上會被埋沒 ⇒ 建議需要時另開專票追。 **未解謎**（07-08 舊 record 同參數曾回正確資料）：物證已滅失（KV 無版本史），且 flag 補上後現象不再出現，無法也不必再追。誠實記錄於此，不擋關閉。

Leo closed this issue

2026-07-31 10:22:14 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: Leo/Arcrun#38