改了設定跑更新，它說「部署完成」但什麼都沒動——跳過的判準只看 code 不看設定 #113

New Issue

2026-08-12T17:23:41Z

Leo commented

2026-08-12 17:23:41 +00:00

症狀（leo 2026-08-13 實撞，兩次連續更新的對照）

改了 ~/.arcrun/config.yaml 的 api_key 之後跑更新，它印：

→ 部署 23 個 worker（未變動者跳過，依序進行）...
    [1/23] array_ops ... ⊘ 未變動，跳過
    …（23 顆全部跳過）
  ✓ 部署完成

「✓ 部署完成」，但設定一個字都沒生效。 使用者沒有任何線索。

對照前一次跑（code 有變）——那次印了這行、這次沒有：

→ 算這趟要烙上去的版本標籤... ✓
  ARCRUN_BUNDLE_VERSION = 1.4.43（…）
  ARCRUN_NAMESPACE = …            ← vars 是在「部署那一步」寫的

⇒ 部署被跳過 ⇒ vars 沒被寫 ⇒ 改設定等於沒改。
實測後果：kbdb_get_map 仍回 0 個庫（Arcrun#108 的修法在 code 裡，但設定沒對齊）。

根因

cli/src/lib/deploy.ts：

:37  部署狀態 manifest：記錄上次成功部署每個 worker 的**內容指紋（content hash）**
:41  MANIFEST_PATH = ~/.arcrun/deploy-manifest.json
:630 內容指紋 manifest：未變動且上次成功的 worker 跳過

🔴 指紋只算 code，不算 vars。 而 vars（ARCRUN_BUNDLE_VERSION／ARCRUN_NAMESPACE／
使用者沿用的那些）是在 wrangler deploy 的當下一起送上去的。
⇒ 只要 code 沒變，vars 的變更就永遠送不出去。

為什麼這比「加 --force 就好」嚴重

它是假綠。 印的是「✓ 部署完成」，不是「沒有東西需要部署」——
使用者（與 AI）都會相信設定生效了，然後去別的地方找原因。
2026-08-13 實際發生：總管改完設定、跑完更新、看到「完成」，
結果地圖仍是空的，又去查了一輪 code。
叫人記得加 --force 不是解法——那是把機器的責任推給記性。
而且 --force 會重部 23 顆（慢、且擴大風險面），只為了改一個 var。
這是「本機是對的，送出去的不是」的最新一例（同一晚已有三例：
.worker-builds 落後源碼／*.sql 被 gitignore 吃掉／bundle 比 main 舊）。
共同形狀：兩個東西該一致，但只有一邊被檢查。

要達成什麼

改了設定跑更新，設定就會生效；如果真的沒事可做，它要說「沒有東西需要更新」而不是「部署完成」。

不指定做法。但有一題請回答：指紋該不該把「這趟要烙的 vars」算進去？
（若算進去，改一個 var 只會重部需要它的那幾顆，而不是 23 顆全上。）

怎麼驗才算數

改 ~/.arcrun/config.yaml 的 api_key → 跑更新（不加 --force）→
cypher 身上的 ARCRUN_NAMESPACE 真的變了（貼更新前後的值）
什麼都不改再跑一次 → 它要誠實說「沒有東西需要更新」，不是「部署完成」
只重部需要的那幾顆——不能為了正確性變成每次都全部重來
回歸：code 有變時的跳過邏輯仍然有效（那是它存在的理由，
壓測 2026-06-12：22/23 成功後重跑仍全部重來）

🔴 收工標準多一條：留一道會擋的閘

leo 2026-08-12 立：「做平台要減少 hotfix。」
本票屬於「兩個東西該一致，但只有一邊被檢查」那一類 ⇒
修掉不算完成，要留下「下次有人加了新的 var 卻沒納入指紋會被擋住」的機制。

閘要滿足：會擋不是只提醒／判準看「有沒有在做那件事」不是「字串有沒有出現」／閘自己要能被測試。

紅線

🔴 不准部署到 leo21c（測試用 youlin）
🔴 不准把跳過邏輯整個拿掉——那是它存在的理由
🔴 不准推 main、不准動 prod

📍 repo：matrix/arcrun（cli/src/lib/deploy.ts、~/.arcrun/deploy-manifest.json）
📍 相關：Arcrun#108（因為本 bug 而看起來像沒修好）｜Arcrun#106（版本標籤也是 var，同一條路）

## 症狀（leo 2026-08-13 實撞，兩次連續更新的對照）改了 `~/.arcrun/config.yaml` 的 `api_key` 之後跑更新，它印： ``` → 部署 23 個 worker（未變動者跳過，依序進行）... [1/23] array_ops ... ⊘ 未變動，跳過 …（23 顆全部跳過） ✓ 部署完成 ``` **「✓ 部署完成」，但設定一個字都沒生效。** 使用者沒有任何線索。對照前一次跑（code 有變）——那次印了這行、這次沒有： ``` → 算這趟要烙上去的版本標籤... ✓ ARCRUN_BUNDLE_VERSION = 1.4.43（…） ARCRUN_NAMESPACE = … ← vars 是在「部署那一步」寫的 ``` ⇒ **部署被跳過 ⇒ vars 沒被寫 ⇒ 改設定等於沒改。** 實測後果：`kbdb_get_map` 仍回 0 個庫（`Arcrun#108` 的修法在 code 裡，但設定沒對齊）。 ## 根因 `cli/src/lib/deploy.ts`： ``` :37 部署狀態 manifest：記錄上次成功部署每個 worker 的**內容指紋（content hash）** :41 MANIFEST_PATH = ~/.arcrun/deploy-manifest.json :630 內容指紋 manifest：未變動且上次成功的 worker 跳過 ``` 🔴 **指紋只算 code，不算 vars。** 而 `vars`（`ARCRUN_BUNDLE_VERSION`／`ARCRUN_NAMESPACE`／使用者沿用的那些）是在 `wrangler deploy` 的當下一起送上去的。 ⇒ **只要 code 沒變，vars 的變更就永遠送不出去。** ## 為什麼這比「加 --force 就好」嚴重 1. **它是假綠。** 印的是「✓ 部署完成」，不是「沒有東西需要部署」—— 使用者（與 AI）都會相信設定生效了，然後去別的地方找原因。 2026-08-13 實際發生：總管改完設定、跑完更新、看到「完成」，結果地圖仍是空的，又去查了一輪 code。 2. **叫人記得加 `--force` 不是解法**——那是把機器的責任推給記性。而且 `--force` 會重部 23 顆（慢、且擴大風險面），只為了改一個 var。 3. **這是「本機是對的，送出去的不是」的最新一例**（同一晚已有三例： `.worker-builds` 落後源碼／`*.sql` 被 gitignore 吃掉／bundle 比 main 舊）。共同形狀：**兩個東西該一致，但只有一邊被檢查。** ## 要達成什麼 **改了設定跑更新，設定就會生效；如果真的沒事可做，它要說「沒有東西需要更新」而不是「部署完成」。** 不指定做法。但有一題請回答：**指紋該不該把「這趟要烙的 vars」算進去？** （若算進去，改一個 var 只會重部需要它的那幾顆，而不是 23 顆全上。） ## 怎麼驗才算數 1. 改 `~/.arcrun/config.yaml` 的 `api_key` → 跑更新（**不加 `--force`**）→ **cypher 身上的 `ARCRUN_NAMESPACE` 真的變了**（貼更新前後的值） 2. 什麼都不改再跑一次 → 它要**誠實說「沒有東西需要更新」**，不是「部署完成」 3. **只重部需要的那幾顆**——不能為了正確性變成每次都全部重來 4. 回歸：code 有變時的跳過邏輯仍然有效（那是它存在的理由，壓測 2026-06-12：22/23 成功後重跑仍全部重來） ## 🔴 收工標準多一條：留一道會擋的閘 leo 2026-08-12 立：「**做平台要減少 hotfix。**」本票屬於「**兩個東西該一致，但只有一邊被檢查**」那一類 ⇒ **修掉不算完成，要留下「下次有人加了新的 var 卻沒納入指紋會被擋住」的機制。** 閘要滿足：會擋不是只提醒／判準看「有沒有在做那件事」不是「字串有沒有出現」／閘自己要能被測試。 ## 紅線 - 🔴 不准部署到 `leo21c`（測試用 youlin） - 🔴 不准把跳過邏輯整個拿掉——那是它存在的理由 - 🔴 不准推 main、不准動 prod 📍 repo：`matrix/arcrun`（`cli/src/lib/deploy.ts`、`~/.arcrun/deploy-manifest.json`） 📍 相關：`Arcrun#108`（因為本 bug 而看起來像沒修好）｜`Arcrun#106`（版本標籤也是 var，同一條路）

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: Leo/Arcrun#113