Bug P1 OpenClaw 2026.8.1 Beta 3: npm install Bisa Memigrasi Database dan Memicu Crash Loop

OpenClaw 2026.8.1-beta.3 resmi terbit pada 24 Agustus 2026. Rilis ini membawa dukungan GPT-5.6 Sol, Terra, Luna, dan Ultra, relay CDP yang lebih kompatibel dengan Puppeteer, backup SQLite yang lebih matang, serta lifecycle Gateway untuk external supervisor.

Masalahnya, ada regression P1 yang membuat proses instalasi jauh lebih berisiko daripada kelihatannya. Menurut issue resmi OpenClaw #128782, menjalankan npm install [email protected] dapat memigrasi database shared state di ~/.openclaw/state/openclaw.sqlite meski binary OpenClaw yang baru belum pernah dijalankan.

Efeknya tidak selalu muncul saat itu juga. Gateway versi lama bisa tetap terlihat sehat karena masih memakai handle database yang sudah terbuka. Crash loop baru terjadi pada restart berikutnya, ketika build lama membaca schema yang sudah dinaikkan oleh package beta.

Keputusan cepat: jangan menguji 2026.8.1-beta.3 pada host production, prefix NPM terpisah, atau checkout percobaan yang masih memakai HOME dan state directory production. Gunakan VM, container, atau environment dengan HOME dan OPENCLAW_STATE_DIR yang benar-benar terisolasi.

Apa yang terjadi?

Reporter issue melakukan reproduksi dengan HOME decoy dan instalasi ke local prefix. Sebelum instalasi, PRAGMA user_version pada database shared state bernilai 5. Setelah npm install, nilainya berubah menjadi 9. Binary baru tidak pernah dipanggil.

Issue itu juga melaporkan bahwa environment variable OPENCLAW_DISABLE_BUNDLED_PLUGIN_POSTINSTALL=1 tidak mencegah perubahan schema tersebut.

Kami memeriksa tarball resmi NPM [email protected]. Bukti pada package yang dipublikasikan konsisten dengan mekanisme yang dijelaskan reporter:

1. package.json mendaftarkan node scripts/postinstall-bundled-plugins.mjs sebagai lifecycle postinstall.
2. Pada direct invocation, script menjalankan runBundledPluginPostinstall() lalu tetap memanggil runPluginRegistryPostinstallMigration().
3. Disable flag di atas hanya menjaga bagian bundled-plugin postinstall. Panggilan migrasi registry berada setelahnya dan tetap dijalankan.
4. Jalur registry migration membuka shared state melalui jalur write normal. Open database tersebut dapat memicu ensureSchema dan forward migration.

Jadi mekanismenya tidak hanya bertumpu pada judul issue. Package resmi memang punya install hook yang masuk ke jalur migrasi registry. Reproduksi perubahan schema v5 ke v9 berasal dari reporter, sementara call chain-nya bisa diverifikasi langsung dari tarball dan source resmi.

Kenapa bug ini berbahaya?

Masalah utamanya adalah batas antara install dan activation menjadi kabur.

Dalam rollout yang aman, operator biasanya melakukan hal berikut:

1. mengunduh atau memasang package baru di lokasi terpisah;
2. menjalankan preflight terhadap salinan state;
3. melakukan smoke test;
4. baru mengganti runtime aktif dan restart service.

Pada beta.3, langkah pertama saja dapat menyentuh state milik instalasi yang sedang berjalan. Artinya, test package di prefix lain belum tentu terisolasi jika proses NPM masih melihat HOME yang sama.

Failure-nya juga tertunda. Saat instalasi selesai tanpa error dan Gateway lama tetap menjawab health check, operator bisa menyimpulkan semuanya aman. Beberapa jam kemudian, scheduled restart atau maintenance restart menjalankan build lama terhadap database schema baru. OpenClaw kemudian menolak database itu dengan error schema lebih baru dan service masuk crash loop.

Pola delayed failure seperti ini lebih sulit didiagnosis daripada install yang langsung gagal. Jarak waktu antara penyebab dan gejala membuat restart, supervisor, atau perubahan lain terlihat sebagai tersangka utama.

Reinstall versi lama bukan rollback database

Dokumentasi schema OpenClaw menjelaskan kontraknya dengan tegas: migration berjalan ke depan, sedangkan build lama menolak database yang sudah ditulis memakai schema lebih baru.

Menurunkan versi package tidak menurunkan schema database. Jika state sudah berubah dari v5 ke v9, reinstall versi lama hanya mengembalikan binary lama. Datanya tetap berada pada schema baru.

Pilihan recovery yang didukung secara konsep adalah:

• memulihkan backup yang dibuat sebelum migration;
• membuka database dengan build yang memang mendukung schema tersebut;
• menjalankan build lama dengan state directory baru yang terpisah.

Jangan mengedit PRAGMA user_version hanya untuk membungkam error. Schema 9 mencakup perubahan struktural pada registry path database agent, bukan hanya perubahan nomor. Memaksa versi turun tanpa membalik semua perubahan schema dapat merusak state atau menghasilkan perilaku yang lebih sulit dipulihkan.

Apakah semua pengguna beta.3 pasti terdampak?

Belum ada dasar untuk mengatakan semua instalasi pasti mengalami crash loop. Issue #128782 masih terbuka saat audit ini dibuat, dan implementasi fix otomatis masih berada pada tahap planning.

Namun threshold untuk menahan rollout production sudah terpenuhi:

• issue diberi label P1;
• dampaknya ditandai data loss dan crash loop;
• reproduksi memakai package beta.3 resmi;
• reviewer upstream mengonfirmasi source saat ini masih memanggil shared-state-writing migration dari NPM postinstall;
• NPM latest masih menunjuk 2026.7.1-2, sementara beta.3 berada pada dist-tag beta.

Ini cukup untuk memperlakukan beta.3 sebagai release yang hanya boleh diuji di environment terisolasi sampai patch tersedia dan reproduksi dinyatakan tertutup.

Cara menguji beta.3 tanpa menyentuh production

Jangan hanya mengganti folder instalasi. Isolasi harus mencakup lokasi state yang dibaca lifecycle script.

Gunakan checklist berikut:

1. Pisahkan host atau namespace. VM disposable atau container lebih aman daripada prefix NPM lain pada akun OS yang sama.
2. Gunakan HOME terpisah. Jangan biarkan proses instalasi melihat ~/.openclaw production.
3. Set OPENCLAW_STATE_DIR ke lokasi canary. Pastikan tidak ada symlink yang kembali ke state utama.
4. Buat backup terverifikasi sebelum install. Pakai jalur backup resmi yang tersedia pada versi Anda atau SQLite online backup yang WAL-aware. Jangan menyalin file .sqlite live sendirian.
5. Catat schema sebelum dan sesudah. Periksa PRAGMA user_version pada salinan database yang terkoordinasi, bukan dengan eksperimen write ke database live.
6. Uji restart, bukan hanya health saat proses lama masih hidup. Canary harus benar-benar berhenti dan start lagi dengan runtime target.
7. Uji rollback dari backup. Jangan menganggap install versi lama cukup.

Command openclaw database preflight <copied-state.sqlite> --json juga relevan untuk mengecek kompatibilitas target release terhadap salinan state. Dokumentasi resmi mengingatkan bahwa input harus berupa snapshot WAL-consistent tanpa sidecar -wal, -shm, atau -journal.

Jika beta.3 sudah terlanjur di-install pada host production

Jangan panik, tetapi jangan restart secara refleks.

Lakukan recovery secara terukur:

1. catat versi dan install root proses Gateway yang sedang berjalan;
2. identifikasi state directory yang benar;
3. hentikan install atau automation lain yang dapat membuka state;
4. buat snapshot WAL-consistent sebelum melakukan perubahan berikutnya;
5. periksa schema pada salinan snapshot;
6. jika schema sudah maju, pilih antara restore backup pra-instalasi atau recovery dengan build yang kompatibel;
7. uji langkah recovery pada copy atau canary sebelum menyentuh service utama.

Jika tidak ada backup sebelum instalasi, jangan improvisasi downgrade schema di production. Pertahankan evidence, buat copy terverifikasi, lalu pilih jalur forward-compatible yang dapat membuka state tersebut. Kehilangan beberapa jam bookkeeping dari restore masih lebih baik daripada merusak database utama karena edit manual yang tidak lengkap.

Beta.3 tetap membawa fitur penting, tetapi timing rollout-nya salah

Secara fitur, 2026.8.1-beta.3 menarik. Release notes resmi menonjolkan dukungan GPT-5.6 yang lebih luas, first-run setup Control UI, CDP relay untuk paired Chrome, backup dan restore SQLite, external Gateway supervision, serta shared durable ingress monitor untuk plugin channel.

Tetapi regression install-time ini menyentuh recovery boundary paling dasar: operator harus bisa memasang package untuk diperiksa tanpa diam-diam mengubah state production.

Sampai fix resmi masuk dan package penggantinya diterbitkan, rekomendasi operasionalnya sederhana:

• production tetap di jalur stable yang sudah diuji;
• beta.3 hanya untuk canary terisolasi;
• backup harus dibuat sebelum instalasi, bukan sesudah restart gagal;
• rollback harus berarti restore state yang kompatibel, bukan hanya reinstall binary lama.

Kesimpulan operasional

OpenClaw 2026.8.1-beta.3 bukan kandidat upgrade production saat ini. Bug P1 #128782 menunjukkan bahwa npm install saja dapat menjadi write operation terhadap shared state dan memajukan schema database tanpa activation eksplisit.

Ini bukan alasan untuk menghindari semua beta selamanya. Ini alasan untuk memperbaiki cara menguji beta: pisahkan HOME, pisahkan state directory, gunakan backup WAL-aware, jalankan preflight pada salinan, dan buktikan restart serta rollback di canary.

Kalau host memegang channel, cron, dan session penting, jangan sentuh beta.3 dari environment yang masih bisa melihat state production.

Sumber primer:

• GitHub Release OpenClaw 2026.8.1-beta.3
• Issue OpenClaw #128782
• Package resmi [email protected] di NPM
• Dokumentasi OpenClaw Database Schemas
• Dokumentasi OpenClaw Backup