 Leo
|
9f64615cfd
|
v0.18.12：出問題時一鍵打開紀錄檔資料夾（leo：「不能用一個 debug mode？」）
leo 08-06：「不能用一個 debug mode，就是它會把 log 寫在一個檔案？」
## 回答：log 一直都在寫，缺的是「找得到」
`~/.arcrun-rag/collector.log`（含 collector 的 stderr，以 `[stderr]` 開頭）
與 `app.log` 從 t14 就在寫。這次 Windows 事故的真正死因
（`config 缺必填欄位：manifest`）**一直躺在 collector.log 裡**，
但使用者只看得到畫面上一句話，沒有任何入口通到那些檔案。
⇒ **不做「debug mode 開關」**（多一個要教使用者的東西，而且出事當下才想到要開就來不及了），
改成**永遠寫、出事時一鍵打開**：
- `OpenLogFolder()` 綁定（Windows 走 explorer／Mac 走 open／其餘 xdg-open）
- 首頁在 `engineTrouble` 時才長出「需要回報這個問題？」卡，附按鈕與**路徑文字**
（按鈕失效時仍找得到）。沒事時不顯示——否則會變常駐噪音，真出事反而沒人看。
## 真機證據：v0.18.10 的「說出死因」有效
leo 的 Windows 畫面實拍：
「同步引擎一直啟動失敗 / 已自動重試 8 次都失敗，所以重新開啟也沒有用。
原因：collector direct: config 缺必填欄位：manifest（exit status 2）」
⇒ **與 v0.18.11 修的根因一字不差**，診斷鏈完整閉合：
症狀（閃爍）→ 機制（子行程 exit 2 無限重拉）→ 死因（config 缺 manifest）→ 修正。
|
2026-08-06 18:47:17 +08:00 |
|
|
Leo
|
fcf00bb5df
|
v0.18.11：修好 Windows「裝了完全不會動」的真兇——全新 config 缺 manifest 欄位
leo 08-06 提供決定性線索：**exit status 2，已自動重試 21 次失敗**。
## 真兇
`app.go` 的 `saveCfg` 只寫四個鍵（accounts／extractor／extractor_explicit／
gemini_api_key），**從來不寫 `manifest`**。
而 `manifest` 是 collector 的必填欄位（`direct.go`：
`if c.Manifest == "" { missing = append(missing, "manifest") }`）
⇒ 讀 config 失敗 → `runDirect` 回 2 → supervisor 無限重拉
⇒ ①「看守中／沒有在跑」一直閃、重開無效（死因沒變）
⇒ ②加資料夾沒反應（collector 從沒跑完一輪）
## 為什麼一路活到封測
**開發機的 config 是舊版留下的、早就有這一欄。**
只有「從零長出 config」的機器才會撞到——也就是**每一台封測者的機器**。
「我這台好好的」正是這個 bug 能活下來的原因。
⇒ 新測試 `TestFreshConfigIsUsableByCollector` **從零建 config**，
並且不只驗欄位在不在，而是**真的餵給 `collector.LoadDirectConfig`**。
已反向驗證：把修正拿掉，測試會紅（不是假測試）。
## 順帶修好「為什麼只看得到 exit status 2」
supervisor 在行程結束時用 `cmd.Wait()` 的錯誤當訊息，
**蓋掉**了 stderr 剛寫進 `LastError` 的那句真話
（`collector direct: config 缺必填欄位：manifest`）。
⇒ 改成以 stderr 為主、退出碼放括號補充。
（v0.18.10 已讓死因上畫面＋進 app.log，這版讓那句話是**對的**那一句。）
## 三種 exit 2 的實測輸出（重現測試打出來的，非推測）
- config 不是合法 JSON → `config JSON 解析失敗：invalid character …`
- 缺必填欄位 → `config 缺必填欄位：manifest, accounts（或 cypher_url 連線設定）`
- Windows 反斜線路徑 → 正常解析（**排除「反斜線害的」這個猜測**）
## 驗
collector 全測試過、app 測試過、mac+windows 皆編得過；
產物 `Arcrun-win-v0.18.11.exe`（22M）已放 leo 桌面。
⚠️ **尚未真機驗**——要 leo 在 Windows 全新裝一次才算通。
|
2026-08-06 18:41:31 +08:00 |
|
|
Leo
|
6698f9fbda
|
v0.18.10：讓「同步引擎沒在跑」說出死因（leo Windows 實測①②的診斷前置）
leo 08-06 Windows 回報：「一直在『看守中』和『沒有在跑』中間閃，要我重啟但重啟無效，
我覺得它在跑個迴圈不停重複」＋「加一個資料夾明顯沒產生看守資料夾」。
朋友的一般 PC（非 ARM）也一樣，停在等待中 ⇒ **不是 ARM 模擬的問題，是 Windows 通用**。
## 已定位的機制（不是根因，是「為什麼查不出根因」）
閃爍＝子行程一啟動就死 → supervisor 退避重拉 → 狀態在 Starting（alive=true）與
Error（false）之間彈跳 ⇒ 畫面跟著閃。而**死因一直被記在 Status().LastError 裡，
從來沒有上過畫面、也沒寫進 app.log** ⇒ 使用者只看到閃爍與「請重新開啟」，
重開當然無效（死因沒變）。這是「安靜地略過」的同一種病換地方發作。
## 這版做的
- 死因上畫面：重試 >= 3 次改顯示「同步引擎一直啟動失敗，已自動重試 N 次｜原因：…」，
且**黏住不閃**（不受重起過程中的 Starting 影響）
- 每次異常結束寫進 app.log（同錯誤 10 次內只記一次，避免洗爆）
## 排除掉的嫌疑（查過，不是）
- PDF 引擎（pdfium/wasm）：**延遲初始化**，第一次讀 PDF 才啟動 ⇒ 不會在啟動時炸
- ARM 模擬：leo 朋友的一般 x64 PC 同樣症狀
- 待查嫌疑：Wails 的 Windows 版是 `-H windowsgui`（GUI subsystem，無主控台），
而 v0.18.8 的 collector.exe 是 `go build` 的 console subsystem——
v0.18.9 合併成單一 binary 後，子行程換成 GUI subsystem 的自己。**尚未證實。**
## 順帶修好自己的閘（它擋對了我）
指紋閘擋下「v0.18.10 已對應另一份原始碼」——因為第一次打包失敗、版號卻已被戳。
⇒ 加判準：**磁碟上沒有該版號產物＝從未出貨，允許重戳**（不用去手改 JSON，
那種爛示範遲早被改成「都放行」）。
## 安裝程式（leo ③）尚未兌現，誠實記錄
`wails build -nsis` 需要 makensis；Homebrew 的 3.12 在這台 macOS **連兩行的最小腳本
都在寫檔階段丟 std::bad_alloc**，zlib/bzip2/lzma 三壓縮器全崩，brew extract 舊版
被 homebrew/core 擋。且帶 -nsis 會讓 wails 整個中止、連 exe 都不產
⇒ build-win.sh 改成**先煙霧測試 makensis**，壞的就只出裸 exe 並大聲警告。
|
2026-08-06 18:27:08 +08:00 |
|
|
Leo
|
0b8bc83bd1
|
版本指紋閘（同一版號只准一份原始碼，實測有效）＋落帳封測兩病與 md 真相
|
2026-08-06 16:17:40 +08:00 |
|