Hermes Agent 0.19.0 sedang menghadapi bug yang level risikonya lebih tinggi dari gangguan UI atau error provider biasa. Runtime Python yang dipilih installer saat ini membawa SQLite 3.50.4, sementara versi tersebut masuk rentang terdampak bug WAL-reset yang dapat menyebabkan database korup saat beberapa proses menulis dan melakukan checkpoint secara bersamaan.
Temuan ini dilaporkan sebagai issue P1 #69784 pada 23 Juli 2026. Belum ada release pengganti untuk 0.19.0 dan belum ada patch resmi Hermes yang tersedia saat artikel ini ditulis.
Status per 23 Juli 2026: stable terbaru tetap Hermes Agent 0.19.0. Temuan ini adalah bug operasional terbuka, bukan GitHub Security Advisory.
Apa sebenarnya yang rusak
Hermes menyimpan state penting di database SQLite seperti state.db dan kanban.db. Database tersebut memakai mode Write-Ahead Logging atau WAL agar beberapa proses bisa membaca dan menulis dengan concurrency yang lebih baik.
Masalahnya ada pada proses reset WAL. Dokumentasi resmi SQLite menjelaskan adanya race condition ketika dua koneksi atau lebih berjalan di thread atau proses berbeda, lalu writer dan checkpointer saling overlap. Dalam timing tertentu, koneksi baru dapat membaca state WAL yang salah dan hasil akhirnya bukan sekadar transaksi gagal: isi database utama dapat korup.
SQLite memperbaiki bug ini di versi 3.51.3. Backport juga tersedia untuk beberapa branch, termasuk 3.50.7. Runtime Hermes yang dilaporkan masih memakai 3.50.4, jadi mengganti minor Python atau menginstall ulang Python dari jalur yang sama belum tentu mengubah library SQLite yang tertanam.
Kenapa Hermes cocok dengan kondisi pemicu
Issue resmi mencatat pola yang sangat dekat dengan syarat bug upstream:
- gateway, dispatcher, dashboard atau CLI, cron, dan worker dapat membuka database yang sama;
- database berjalan dalam mode WAL;
- beberapa proses melakukan write, checkpoint, health probe, dan reconnect dalam waktu berdekatan;
- worker dapat berhenti mendadak saat proses lain masih aktif.
Kombinasi ini bukan edge case teoritis untuk deployment aktif. Semakin ramai automation, cron, dan worker berjalan bersamaan, semakin realistis overlap tersebut terjadi.
Reporter menguji workload berbasis schema dan jalur koneksi Hermes. Dua run dengan SQLite 3.50.4 menghasilkan anomali selama proses dan database korup pada pemeriksaan akhir. Run pembanding dengan SQLite 3.51.3 menyelesaikan workload tanpa anomali dan lolos integrity check.
Ini belum sama dengan patch resmi yang sudah direview maintainer. Namun kecocokan antara versi terdampak, mekanisme upstream, bentuk kerusakan, dan hasil A/B membuat temuan ini layak diperlakukan serius.
Dampak yang mungkin terlihat
Korupsi tidak selalu muncul sebagai crash total. Gejalanya dapat terlihat seperti masalah aplikasi biasa:
- session history hilang atau tidak konsisten;
- index dan tabel melaporkan jumlah row berbeda;
- event kanban tidak terbaca meskipun sebelumnya berhasil ditulis;
database disk image is malformedatau error B-tree;- health probe menemukan kerusakan setelah layanan terlihat normal;
- repair index berhasil sementara, lalu masalah muncul lagi.
Hardening yang sudah ada di Hermes, termasuk health check, quarantine, backup retention, dan auto-REINDEX, membantu mendeteksi atau memulihkan sebagian kerusakan. Semua itu bekerja setelah masalah terjadi. Selama runtime masih memakai SQLite rentan, akar risikonya belum hilang.
Jangan langsung melakukan swap library sembarangan
Solusi paling menggoda adalah memasang pysqlite3-binary lalu mengganti import. Itu belum aman dijadikan resep umum.
Issue #69784 mencatat package binary yang tersedia saat pengujian masih membawa SQLite 3.51.1, yang juga berada sebelum perbaikan 3.51.3. Custom build 3.51.3 memang lolos corruption harness, tetapi memunculkan perbedaan perilaku transaksi pada sembilan test hermes_state.
Artinya, targetnya bukan hanya "versi SQLite lebih baru". Runtime baru juga harus lolos compatibility test Hermes.
Langkah aman untuk operator 0.19.0
Sambil menunggu keputusan maintainer, jalur paling waras adalah mengurangi risiko dan memperkuat recovery.
1. Cek versi SQLite yang benar-benar dipakai
Jangan menyimpulkan versi dari package manager OS. Periksa dari interpreter Python yang dipakai proses Hermes:
python -c "import sqlite3; print(sqlite3.sqlite_version)"
Jika Hermes memakai virtual environment atau managed runtime sendiri, jalankan pemeriksaan dari interpreter tersebut.
2. Backup database dengan metode yang konsisten
Jangan menyalin file database aktif sendirian lalu mengabaikan file -wal dan -shm. Dokumentasi SQLite memperingatkan bahwa database dan hot journal harus diperlakukan sebagai satu state.
Gunakan backup API, VACUUM INTO, atau hentikan writer secara terkontrol sebelum mengambil salinan file. Simpan beberapa generasi backup, bukan hanya satu snapshot terakhir.
3. Jalankan integrity check terjadwal
Pemeriksaan sederhana:
PRAGMA quick_check;
Untuk investigasi lebih dalam gunakan PRAGMA integrity_check;, lalu bandingkan jumlah row tabel dengan index penting. Alarm harus memicu sebelum backup sehat tertimpa snapshot yang sudah korup.
4. Hindari restart paksa dan process churn yang tidak perlu
Bug upstream membutuhkan concurrency dan overlap checkpoint. Mengurangi worker yang dibunuh paksa bukan jaminan bebas korupsi, tetapi dapat memperkecil tekanan pada window yang bermasalah.
Untuk automation kritis, batasi concurrency sementara dan hindari beberapa proses maintenance menyentuh database yang sama pada waktu bersamaan.
5. Jangan anggap REINDEX sebagai fix permanen
REINDEX dapat memperbaiki ketidaksesuaian index tertentu. Jika tabel utama atau page database sudah rusak, hasilnya terbatas. Bahkan ketika repair berhasil, runtime rentan masih dapat mengulang kejadian.
6. Tunggu patch stable dan uji restore
Saat Hermes merilis runtime dengan SQLite fixed, jangan langsung upgrade production tanpa rehearsal. Uji versi SQLite efektif, migration, session resume, cron, kanban, backup, restore, serta behavior transaksi.
Perlu downgrade atau tidak?
Belum ada dasar kuat untuk downgrade massal. Versi lama yang memakai SQLite dari rentang terdampak belum tentu lebih aman, sedangkan 0.19.0 membawa banyak perbaikan reliability lain.
Keputusan yang lebih masuk akal:
- deployment ringan, single-user: tetap di stable, pastikan backup konsisten dan integrity check aktif;
- gateway ramai dengan cron dan banyak worker: kurangi concurrency yang tidak perlu, tingkatkan frekuensi pemeriksaan, dan siapkan maintenance window untuk patch;
- database sudah menunjukkan error: hentikan write secara terkontrol, amankan seluruh file database beserta WAL terkait, lalu pulihkan dari backup sehat. Jangan terus menjalankan workload pada file yang dicurigai korup.
Kesimpulan operasional
Hermes Agent 0.19.0 belum punya release pengganti, tetapi operator sebaiknya tidak menganggap state.db dan kanban.db aman hanya karena agent masih bisa menjawab. Bug yang sedang diaudit berada di layer penyimpanan dan dapat baru terlihat setelah history, event, atau index dibutuhkan.
Prioritas hari ini bukan eksperimen mengganti library di production. Verifikasi versi SQLite aktual, pastikan backup konsisten, aktifkan integrity check, kurangi process churn, dan pantau issue #69784 sampai maintainer menetapkan jalur packaging yang sudah lolos compatibility test.
Sumber primer:
Founder Rama Digital. Menulis tentang digital marketing, web development, AI, dan sistem operasional untuk bisnis Indonesia.
Tentang Rama Digital
