uncle6me-web
53b05c6d3d
leo 08-12 實撞：更新完 leo21c，Portal 設定頁的「版本」變成 「無法讀取目前版本（知識庫服務可能正在啟動）」。版本號是 leo 唯一的驗收介面， 看不到就等於他無法自己確認任何一次更新有沒有生效。 根因（Arcrun#106）：`bundle_version` 來自部署時注入的 plain_text var `ARCRUN_BUNDLE_VERSION`，而**只有安裝器會注入**。wrangler deploy 是整份覆蓋， toml 沒寫的 var 直接消失 ⇒ CLI 更新那條路每跑一次就把標籤洗掉一次。 #97 修好了「櫃子」（KV/D1/Vectorize 沿用既有），沒修「櫃子上的標籤」。 修法（兩種 var 走相反的規則，這是本次的判斷）： · 設定類 var ＝ 使用者實例的事實 → **沿用**（讀綁定時同一份回應就帶回來，不多打 API） ——把 #97「已部署的 worker 上綁著什麼就是事實」原封不動套用到 plain_text var。 · 版本標籤 ＝ 這份成品的屬性 → **每趟重烙，絕不沿用舊值**。 沿用舊值會得到一個永遠停在安裝當天的假標籤——比沒有標籤更糟， 因為它會讓人以為驗收過了。 版號取部署當下發行頻道公告的 release（Portal/daemon 就是拿它當「最新版」比）， 另外把**真正部署的 commit** 一起烙上去（/health 多吐 `bundle_commit`）→ 漂掉查得出來。 查不到 release 就誠實退成 `YYYY-MM-DD+<commit7>`，不掰一個 semver 假裝已是最新。 順帶（都是同一條路上的東西）： · ref 先解析成 commit sha 再用 sha 下載 archive——不可變，順手解掉 branch tarball 被快取的老病 · Portal 版本行接受帶 build metadata 的 semver（`1.4.41+d61` 這種先前一律被當成「較舊版本」） · cli 測試在 node 22 上本來一支都跑不起來（.js→.ts 解析 + parameter property），補上 resolve hook ——#97 那份「使用者的東西還在不在」的迴歸守衛也在其中，跑不起來的守衛等於沒有守衛 · types.ts 的 ARCRUN_BUNDLE_VERSION 重複宣告（TS2300）併回一處 驗證見 PR：cli 49/49 綠、cypher health 4/4 綠、Portal 版本行原始碼實跑五種情境、 對真實已部署 worker 的唯讀 dry-run。**未做**：真實實例上的 acr update 端到端 （本機唯一有憑證的帳號是 leo21c＝紅線禁碰，youlin 無憑證）。 Refs: Leo/Arcrun#106, #97, #95 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
48 lines
3.1 KiB
TypeScript
48 lines
3.1 KiB
TypeScript
import { Hono } from 'hono';
|
||
import type { Bindings } from '../types';
|
||
import { authStoreStatus } from '../lib/portal-auth-store';
|
||
|
||
export const healthRouter = new Hono<{ Bindings: Bindings }>();
|
||
|
||
// t162（leo 07-31 實撞：「小幫手一直顯示知識庫需要更新…重新更新後並不會消失」）：
|
||
// daemon cloudVersionStale() 讀 /health 的 `bundle_version` 判斷是否過舊——
|
||
// 但本端點過去只回 {ok:true}，**從沒吐這個欄位** ⇒ daemon 恆讀到空字串
|
||
// ⇒ 恆判 stale ⇒ 假警報永遠不消失（安裝器其實一直有注入 ARCRUN_BUNDLE_VERSION var，
|
||
// 只是沒有人把它吐出來）。修＝誠實回報本實例的 bundle 版本。
|
||
// 未注入（本地 dev／很舊的實例）就省略該欄——daemon 對空字串仍判 stale，
|
||
// 那是**正確的**（真的是老實例，該更新）。
|
||
// D61（ADR D61 / Leo/arcrun-rag#55）：多吐一個 `auth_store`——「認證住哪、寫不寫得進去」
|
||
// 要在實例自己這一側就看得出來，不是等用戶登不進去才發現（#10「寧可明顯失敗」）。
|
||
// 只回統計不回內容（帳號數／有沒有 console 帳密／分片數），不洩漏任何 email 或雜湊。
|
||
// bundle_version 的既有行為不動（未注入就省略該欄——daemon 對空字串判 stale 是正確的）。
|
||
// Arcrun#106（leo 08-12 實撞：更新完設定頁變成「無法讀取目前版本」）：
|
||
// `bundle_version` 只在部署時被注入，而**只有安裝器會注入**——CLI 更新那條路重部署
|
||
// 等於把這個標籤洗掉（wrangler deploy 整份覆蓋，toml 沒寫的 var 直接消失）。
|
||
// 修在 CLI 那側（cli/src/lib/deploy.ts：既有 var 沿用 + 版本標籤每趟重烙）。
|
||
// 這裡只多吐一個 `bundle_commit`：版號是「發行頻道的編號」，commit 才是「真的部了哪份碼」——
|
||
// 兩個一起看才有辦法查「標籤有沒有跟成品漂掉」。沒注入就省略該欄（同 bundle_version 的既有行為）。
|
||
healthRouter.get('/health', (c) => {
|
||
const bundleVersion = c.env.ARCRUN_BUNDLE_VERSION;
|
||
const bundleCommit = c.env.ARCRUN_BUNDLE_COMMIT;
|
||
return c.json({
|
||
ok: true,
|
||
...(bundleVersion ? { bundle_version: bundleVersion } : {}),
|
||
...(bundleCommit ? { bundle_commit: bundleCommit } : {}),
|
||
auth_store: authStoreStatus(c.env),
|
||
// arcrun-rag#38/#69/#25（2026-08-11）：安裝器判斷「要不要重推」只比 bundle_version——
|
||
// 但這次要修的洞是「installer 從沒注入過 PORTAL_MAIL_RELAY_BASE」，跟 bundle 內容
|
||
// 版本無關（同一個 cypher 版本，有的實例有這個 var、有的沒有）。純比版本號的話，
|
||
// 已經在最新版的實例（如 leo 自己那台）永遠不會因為「按更新」而重推，這個 var
|
||
// 就永遠補不進去。只回布林（有沒有設，不回值本身）——不洩漏郵差網址。
|
||
mail_relay_configured: Boolean(String(c.env.PORTAL_MAIL_RELAY_BASE ?? '').trim()),
|
||
});
|
||
});
|
||
|
||
healthRouter.get('/', (c) =>
|
||
c.json({
|
||
service: 'arcrun-cypher-executor',
|
||
version: '1.0.0',
|
||
status: 'ok',
|
||
})
|
||
);
|