我按了更新，我的工作流和登入全不見了（資料沒掉，但 worker 被綁到全空的新抽屜） #97

New Issue

2026-08-12T04:07:00Z

Leo commented

2026-08-12 04:07:00 +00:00

我按了更新，然後我的東西全不見了。 工作流一支都沒有、portal 把我登出、零件解不出來。

（資料沒掉——但當下看起來就是全沒了。這一點本身就是最傷的部分。）

實撞（leo21c，2026-08-12 12:0x）

跑 acr update → 23/23 worker 部署成功。跑完之後：

namespace leo        → 0 支工作流（更新前有 4 支）
namespace bfezv28v   → 0 支
出貨線第一關當場擋下：「那台實例上沒有這些工作流：ship_check_live、ship_refresh_cdn」

查 Cloudflare：帳號上的 KV 從 9 顆變成 18 顆，而 worker 綁的是新建的那 9 顆（全空）。

舊 webhooks   ba285460…   9 把 key ← 他的工作流在這
新 WEBHOOKS   5a43054d…   0 把 key ← worker 現在指這顆
舊 sessions   2526c1f5…   7 把 key ← 他的登入在這
舊 recipes    b4cbceb3…  80 把 key

根因：兩邊各自決定 KV 要叫什麼名字

誰建的	名字長什麼樣
安裝器（使用者實際在用的那套）	`arcrun-rag-<namespace>-kv-webhooks`
更新指令找的	`WEBHOOKS`、`SESSIONS_KV`、`RECIPES`…（`cli/src/lib/deploy.ts:120` 直接拿 binding 名當標題）

ensureKvNamespace(title, existing) 照標題找 → 找不到就建新的 → 部署綁新的。
它的註解寫著這是「冪等：已存在則重用」——在安裝器裝出來的實例上，那個前提不成立。

⇒ 任何「用安裝器裝、之後跑更新」的人都會撞到這個。 不是 leo 一台的問題。

為什麼特別嚴重

症狀是「東西全不見了」——最容易讓人以為資料沒了、去做更危險的補救動作
更新指令是唯一的補裝管道（Leo/Arcrun#4），而它現在會弄壞實例
部署全綠、23/23 ✓，沒有任何一行說「你的資料現在看不到了」

要達成什麼

跑更新之後，使用者的東西還在原地。 不是「可以還原」，是不該壞。

怎麼驗才算數

拿一台安裝器裝出來的實例（不是手動建的），跑更新前後各列一次工作流／登入狀態，數量一致
帳號上的 KV 顆數不增加
貼前後對照的實際輸出

紅線

不准用「叫使用者自己去改名字」收尾——他不該知道 KV 這種東西存在
不准只改更新那一側就結案：兩邊各自決定名字才是病根，只改一邊下次還會漂
動之前先確認現場那 9 顆有資料的一顆都不能刪

相關

Leo/Arcrun#4（更新是唯一補裝管道）｜Leo/Arcrun#96（舊 CLI 打停用帳號、失敗被 ✓ 夾住）｜
Leo/Arcrun#95（畫面說已是最新版但引擎是舊的）｜Leo/mira#8（安裝器自己從 email 算庫名 —— 同一種「系統替使用者決定名字」）

**我按了更新，然後我的東西全不見了。** 工作流一支都沒有、portal 把我登出、零件解不出來。（**資料沒掉**——但當下看起來就是全沒了。這一點本身就是最傷的部分。） ## 實撞（leo21c，2026-08-12 12:0x）跑 `acr update` → 23/23 worker 部署成功。跑完之後： ``` namespace leo → 0 支工作流（更新前有 4 支） namespace bfezv28v → 0 支出貨線第一關當場擋下：「那台實例上沒有這些工作流：ship_check_live、ship_refresh_cdn」 ``` 查 Cloudflare：**帳號上的 KV 從 9 顆變成 18 顆**，而 worker 綁的是新建的那 9 顆（全空）。 ``` 舊 webhooks ba285460… 9 把 key ← 他的工作流在這新 WEBHOOKS 5a43054d… 0 把 key ← worker 現在指這顆舊 sessions 2526c1f5… 7 把 key ← 他的登入在這舊 recipes b4cbceb3… 80 把 key ``` ## 根因：兩邊各自決定 KV 要叫什麼名字 | 誰建的 | 名字長什麼樣 | |---|---| | 安裝器（使用者實際在用的那套） | `arcrun-rag-<namespace>-kv-webhooks` | | 更新指令找的 | `WEBHOOKS`、`SESSIONS_KV`、`RECIPES`…（`cli/src/lib/deploy.ts:120` 直接拿 binding 名當標題） | `ensureKvNamespace(title, existing)` 照標題找 → **找不到就建新的** → 部署綁新的。它的註解寫著這是「冪等：已存在則重用」——**在安裝器裝出來的實例上，那個前提不成立。** ⇒ **任何「用安裝器裝、之後跑更新」的人都會撞到這個。** 不是 leo 一台的問題。 ## 為什麼特別嚴重 1. **症狀是「東西全不見了」**——最容易讓人以為資料沒了、去做更危險的補救動作 2. **更新指令是唯一的補裝管道**（`Leo/Arcrun#4`），而它現在會弄壞實例 3. 部署全綠、23/23 ✓，**沒有任何一行說「你的資料現在看不到了」** ## 要達成什麼 **跑更新之後，使用者的東西還在原地。** 不是「可以還原」，是**不該壞**。 ## 怎麼驗才算數 1. 拿一台**安裝器裝出來的**實例（不是手動建的），跑更新前後各列一次工作流／登入狀態，數量一致 2. 帳號上的 KV 顆數不增加 3. 貼前後對照的實際輸出 ## 紅線 - 不准用「叫使用者自己去改名字」收尾——他不該知道 KV 這種東西存在 - 不准只改更新那一側就結案：**兩邊各自決定名字**才是病根，只改一邊下次還會漂 - 動之前先確認現場那 9 顆有資料的**一顆都不能刪** ## 相關 `Leo/Arcrun#4`（更新是唯一補裝管道）｜`Leo/Arcrun#96`（舊 CLI 打停用帳號、失敗被 ✓ 夾住）｜ `Leo/Arcrun#95`（畫面說已是最新版但引擎是舊的）｜`Leo/mira#8`（安裝器自己從 email 算庫名 —— 同一種「系統替使用者決定名字」）

Leo commented

2026-08-12 04:43:28 +00:00

🔴 同一個病還有第二層：D1，而且更嚴重（2026-08-12 稍晚）

KV 那層修好之後，leo 打開他的實例說：「leo21c 是掛掉的，總圖沒東西，
4 個 workflows 有一個 failed，子庫全不見了。」

根因一模一樣，只是換一種資源

acr update 裡有一步「D1 arcrun-kbdb（冪等）✓」——它也是照名字找。
而 leo 當天早上剛把叫這個名字的舊庫刪掉（那顆確實該刪，是還原前的舊拷貝）
⇒ 它建了一顆全新的空 D1 並把 kbdb 綁上去（6c1d1dd9…，建於 2026-08-12T03:27:48Z）。

新建的空庫  6c1d1dd9-3b35-40e0-baab-70bfc7eee91b   entries =       5   ← kbdb 在讀這顆
leo 的知識庫 516884ce-b11a-4a9d-9ff5-524d4a111ed1   entries = 493,145

這一層比 KV 更難修

D1 不支援改名——PUT 要求 read_replication、PATCH 直接回
Unrecognized key(s) in object: 'name'。
⇒ KV 那招（改名讓開＋改名接手）在這層行不通，只能直接改 worker 的 binding，
而那是下次跑更新就會被蓋掉的治標。

因此這張票的範圍要擴大

原本寫的是「更新會另建一整套空 KV」。實際上是：
凡是「照名字 ensure 資源」的地方都有這個病——KV 九顆、D1 一顆，
下一個可能是 Vectorize（那支也是 ensureVectorizeMetadataIndexes）。

⇒ 要修的不是「KV 那段」，是**「照名字 ensure」這個做法本身**：
使用者的資源叫什麼名字，不該由更新指令這一側決定。

額外一條實測到的判準

「工作流列得出來」不等於「實例是好的」。 我修完 KV、確認 9 支工作流回來、
綁定也對，就宣布救回來了——而 leo 一打開，總圖是空的。
資料層綁錯的時候，工作流列表照樣正常，因為那是另一顆 KV。

⇒ 復原的驗收標準要是使用者真的會打開的那個畫面，不是任何中間層的清單。

## 🔴 同一個病還有第二層：**D1**，而且更嚴重（2026-08-12 稍晚） KV 那層修好之後，leo 打開他的實例說：**「leo21c 是掛掉的，總圖沒東西， 4 個 workflows 有一個 failed，子庫全不見了。」** ### 根因一模一樣，只是換一種資源 `acr update` 裡有一步「D1 `arcrun-kbdb`（冪等）✓」——**它也是照名字找**。而 leo 當天早上剛把叫這個名字的舊庫刪掉（那顆確實該刪，是還原前的舊拷貝） ⇒ **它建了一顆全新的空 D1 並把 kbdb 綁上去**（`6c1d1dd9…`，建於 `2026-08-12T03:27:48Z`）。 ``` 新建的空庫 6c1d1dd9-3b35-40e0-baab-70bfc7eee91b entries = 5 ← kbdb 在讀這顆 leo 的知識庫 516884ce-b11a-4a9d-9ff5-524d4a111ed1 entries = 493,145 ``` ### 這一層比 KV 更難修 **D1 不支援改名**——`PUT` 要求 `read_replication`、`PATCH` 直接回 `Unrecognized key(s) in object: 'name'`。 ⇒ KV 那招（改名讓開＋改名接手）在這層行不通，只能直接改 worker 的 binding，而那是**下次跑更新就會被蓋掉的治標**。 ### 因此這張票的範圍要擴大原本寫的是「更新會另建一整套空 KV」。實際上是： **凡是「照名字 ensure 資源」的地方都有這個病**——KV 九顆、D1 一顆，下一個可能是 Vectorize（那支也是 `ensureVectorizeMetadataIndexes`）。 ⇒ 要修的不是「KV 那段」，是**「照名字 ensure」這個做法本身**：使用者的資源叫什麼名字，不該由更新指令這一側決定。 ### 額外一條實測到的判準 **「工作流列得出來」不等於「實例是好的」。** 我修完 KV、確認 9 支工作流回來、綁定也對，就宣布救回來了——**而 leo 一打開，總圖是空的**。資料層綁錯的時候，工作流列表照樣正常，因為那是另一顆 KV。 ⇒ 復原的驗收標準要是**使用者真的會打開的那個畫面**，不是任何中間層的清單。

Leo commented

2026-08-12 06:05:11 +00:00

✅ 2026-08-12 傍晚：修好了，而且在 leo 的真機上驗過

併於 d7c6bd0（分支 fix/adopt-live-bindings-97）。

修法：不再用名字找資源 → 已部署的 worker 綁著什麼，那就是事實
（新檔 cli/src/lib/resource-resolver.ts）。三條規則：
① 綁著的原封沿用　② 只有「確定沒人綁過」才准新建　③ 說不準就整趟停手。

真機前後對照（leo 自己在他那台跑 update）

KV  18 顆 → 18 顆   ✅ 沒多生（修法之前那次是 9 → 18）
D1   2 顆 →  2 顆   ✅ 沒多生（之前 1 → 2）
綁定                ✅ 沒被換走（kbdb DB／cypher CREDENTIALS_DB 都還指向 516884ce）
工作流 leo 4 ＋ bfezv28v 5 ＝ 9 支  ✅ 都在

這是那天第一次「跑更新沒有弄壞東西」。

本機驗證

新測試 20 條全過（含四種「說不準就停手」情境）｜CLI 全套 38 pass / 0 fail
反向驗證：把「照名字 ensure」原語加回去 ⇒ 紅線測試當場變紅（0 pass / 1 fail）
重編 dist：ensureKvNamespace／ensureD1Database 在產物裡 0 個

那條線做了三件我沒交辦的

紅線測試：cf-api 不得再提供任何「找不到同名就順手建一顆」的原語
紅線測試：只有 resource-resolver 能決定要不要建，指令層不得自己呼叫 create*
跨租戶外洩：部署出去的 toml 不得殘留官方帳號的資源 id（自架寫進官方庫）

🔑 順帶記一條會省下未來很多時間的

leo 的 acr 是 npm link 到 repo 的 cli/dist/
⇒ CLI 的修法不需要出貨、不需要部署，本機重編完他手上那支立刻就是修好的。

仍未收

CONSOLE_TENANT 這種「使用者身分由部署設定決定」的東西還在——同一個病的殘留。
今天是把值從 leo 改成 bfezv28v 止血，不是修好。

## ✅ 2026-08-12 傍晚：修好了，而且**在 leo 的真機上驗過** 併於 `d7c6bd0`（分支 `fix/adopt-live-bindings-97`）。 **修法**：不再用名字找資源 → **已部署的 worker 綁著什麼，那就是事實** （新檔 `cli/src/lib/resource-resolver.ts`）。三條規則： ① 綁著的原封沿用　② 只有「確定沒人綁過」才准新建　③ **說不準就整趟停手**。 ### 真機前後對照（leo 自己在他那台跑 update） ``` KV 18 顆 → 18 顆 ✅ 沒多生（修法之前那次是 9 → 18） D1 2 顆 → 2 顆 ✅ 沒多生（之前 1 → 2）綁定 ✅ 沒被換走（kbdb DB／cypher CREDENTIALS_DB 都還指向 516884ce）工作流 leo 4 ＋ bfezv28v 5 ＝ 9 支 ✅ 都在 ``` **這是那天第一次「跑更新沒有弄壞東西」。** ### 本機驗證 ``` 新測試 20 條全過（含四種「說不準就停手」情境）｜CLI 全套 38 pass / 0 fail 反向驗證：把「照名字 ensure」原語加回去 ⇒ 紅線測試當場變紅（0 pass / 1 fail）重編 dist：ensureKvNamespace／ensureD1Database 在產物裡 0 個 ``` ### 那條線做了三件我沒交辦的 1. **紅線測試**：`cf-api` 不得再提供任何「找不到同名就順手建一顆」的原語 2. **紅線測試**：只有 resource-resolver 能決定要不要建，指令層不得自己呼叫 `create*` 3. **跨租戶外洩**：部署出去的 toml 不得殘留官方帳號的資源 id（自架寫進官方庫） ### 🔑 順帶記一條會省下未來很多時間的 leo 的 `acr` 是 `npm link` 到 repo 的 `cli/dist/` ⇒ **CLI 的修法不需要出貨、不需要部署**，本機重編完他手上那支立刻就是修好的。 ### 仍未收 `CONSOLE_TENANT` 這種「使用者身分由部署設定決定」的東西還在——同一個病的殘留。今天是把值從 `leo` 改成 `bfezv28v` 止血，**不是修好**。

Leo referenced this issue from a commit

2026-08-12 13:58:55 +00:00

fix(cli): 更新完還看得到版本號——CLI 重部署不再把版本標籤（和你的設定）洗掉

Leo referenced this issue from a commit

2026-08-12 15:37:12 +00:00

refactor(shared): 「該用哪些資源」搬出 CLI——一份實作，acr 與安裝器吃同一條規則

Leo referenced this issue

2026-08-12 15:39:22 +00:00

把「該用哪些資源」搬出 CLI——一份實作，acr 與安裝器吃同一條規則 #111

Leo referenced this issue from a commit

2026-08-15 17:53:13 +00:00

fix(resource-rule): 上次裝到一半死掉的帳號要能再裝一次（Arcrun#123）