更新後 cron job 掛了,想跑路。後來借了一套做研究的思路,三步驟夠用
看到那篇 Reddit,Cannot find module './run-attempt-4t06MuNr.js' 那串,整個人笑了。不是幸災樂禍,是「我也去過那個地方」的那種笑。
我做研究的關係,對「環境可重現性」這件事有點執念。論文跑實驗,得 pin 好 Python 版本、cuda 版本、每個 package 的 hash,不然同樣一份 code 在別人機器上跑出不同結果,直接 reject。不知道從哪天開始,把同樣的思路搬到日常維運上了。
說起來,OpenClaw 更新的坑跟研究環境的坑本質上一樣:你以為在用一個穩定的東西,結果它在你看不到的地方已經換了一批零件。
每次 OpenClaw 有更新通知,我不會馬上 brew upgrade。先做三件事。
確認現有版本,記下來。 openclaw --version 的輸出貼到 versions.log,附上日期。土方法,查起來秒找。
掃 changelog 的破壞性改動。 主要找兩類:internal module 路徑有沒有改(就是那個 run-attempt-*.js 問題),還有 cron/scheduler 相關的 interface 有沒有動。changelog 不清楚的話就翻 release diff 或 issue list。
測試環境先跑 72 小時,確認 cron job 沒有新錯誤,再更新正式環境。 72 小時不是亂設的,我最長的 job 執行週期是 24 小時一次,三個完整週期才算有把握。你的 job 如果是每週跑,就要等更長。
然後要有回滾能力。brew pin openclaw 可以鎖住版本,就算跑 brew upgrade 也不會動到。需要回舊版的話,brew install [email protected] 可以指定(前提是 formula 有支援)。更穩的做法是在啟動腳本裡加 version check,版本不對就噴 warning 或直接拒絕啟動。有點過度設計,但被坑一次之後我加了,確實有用。
這件事讓我想到研究圈的 reproducibility crisis。論文的 conda environment 跑完實驗就沒人管,等半年後有人要複現,才發現哪個 package 已經 deprecate。維運也一樣——OpenClaw cron job 平時好好的,沒人去碰,直到一次更新全掛。問題不在更新本身,在更新之前完全沒有預警機制。
我現在對自己的要求是:任何自動化的東西,README 裡要寫清楚「它依賴什麼版本的什麼」。下次炸的時候,至少知道從哪裡開始查。
博士念太久,養成一個壞習慣,任何東西都想做到 reproducible。但維運這件事上,這個習慣還挺好用的。
作者:十年大博士