Hermes Agent 0.19.0 Bisa Diam Permanen Setelah Error Telegram

Hermes Agent 0.19.0 punya bug P1 yang dapat membuat bot Telegram berhenti menerima pesan setelah gangguan jaringan sementara. Proses gateway tetap hidup, status terakhir terlihat seperti sedang mencoba pulih, tetapi platform tidak pernah masuk antrean reconnect. Dari luar, operasional tampak normal sampai pengguna sadar bot sudah diam berjam-jam atau bahkan berhari-hari.

Temuan ini didokumentasikan pada issue #74494 tanggal 30 Juli 2026. Pelapor mereproduksinya dengan memutus jaringan container sekitar sembilan menit dan menyebut dua insiden produksi, termasuk outage Telegram selama dua hari setelah respons 502 dari API Telegram.

Status per 30 Juli 2026: bug mengenai release Hermes Agent 0.19.0 / v2026.7.20. Perbaikannya sudah ada di branch main melalui commit 2ab153218, tetapi belum masuk release resmi baru.

Gejalanya: gateway hidup, Telegram mati

Bug ini berbahaya karena bukan crash yang langsung terlihat. Hermes sempat menulis log fatal seperti ini:

Fatal telegram adapter error (telegram_network_error): ... Restarting gateway.

Setelah itu tidak ada proses recovery yang benar-benar berjalan. Log Restarting gateway juga menyesatkan untuk deployment tanpa supervisor karena gateway tidak otomatis me-restart dirinya sendiri.

Tanda operasional yang dilaporkan:

• proses gateway masih hidup;
• state platform berhenti pada status retrying;
• antrean _failed_platforms kosong;
• jumlah update Telegram yang tertunda tidak bergerak;
• reconnect watcher terus idle karena tidak menemukan platform yang harus dicoba ulang;
• bot tidak menerima pesan baru sampai proses di-restart manual.

Karena prosesnya tidak mati, health check yang hanya memeriksa PID atau port dapat tetap hijau. Monitoring baru bereaksi kalau ada synthetic message test, pemeriksaan pending update, atau alert berbasis aktivitas pesan.

Akar masalahnya ada di cancellation antar-task

Saat Telegram kehabisan jatah network retry, fatal handler berjalan di dalam task polling adapter. Handler lalu memanggil proses disconnect melalui wrapper task baru.

Masalahnya, TelegramAdapter.disconnect() membatalkan polling error task. Guard yang seharusnya mencegah task membatalkan dirinya sendiri tidak bekerja karena disconnect sekarang berjalan sebagai sibling task. Dari sudut pandang asyncio.current_task(), keduanya memang berbeda.

CancelledError kemudian menghentikan fatal handler sebelum kode sempat memasukkan Telegram ke antrean reconnect. Hasil akhirnya aneh tetapi konsisten: adapter sudah dilepas, platform belum dijadwalkan untuk pulih, dan gateway utama tetap berjalan.

Ini bukan sekadar teori dari pembacaan kode. Reproduksi asyncio minimal pada issue menunjukkan baris antrean recovery tidak pernah tercapai. Reviewer upstream juga memverifikasi mekanisme tersebut terhadap source saat ini.

Kenapa gangguan 502 bisa berubah menjadi outage dua hari

Respons 502, timeout, atau gangguan koneksi seharusnya menjadi insiden sementara. Adapter mencoba ulang, masuk backoff, lalu reconnect ketika jaringan pulih.

Pada bug ini, kegagalan terakhir justru memotong handoff dari adapter ke gateway. Setelah platform terlepas, tidak ada lagi komponen yang memegang tanggung jawab recovery.

Artinya, durasi outage tidak lagi ditentukan oleh durasi gangguan Telegram. Outage berlangsung sampai operator me-restart gateway, supervisor mendeteksi kegagalan, atau deployment diganti dengan build yang sudah memuat patch.

Ada satu jebakan: supervisor berbasis process liveness saja tidak akan bertindak karena gateway masih hidup.

Patch di main membuat handoff tahan cancellation

Commit 2ab153218 mengubah shared gateway dispatch, bukan hanya menambal satu cabang Telegram.

Perbaikannya terdiri dari dua lapis:

• fatal handler utama dijalankan sebagai detached task dan ditunggu melalui asyncio.shield(), sehingga cancellation dari task pemanggil tidak ikut membunuh proses handoff;
• jika platform retryable tetap tidak berada di daftar adapter aktif maupun antrean gagal, gateway keluar dengan status failure agar systemd, launchd, atau supervisor lain dapat me-restart proses.

Lapisan kedua penting. Kalau recovery internal tetap gagal karena kondisi lain, gateway tidak dibiarkan terlihat sehat sambil kehilangan satu platform secara permanen.

Patch ini sudah ada di main sejak 21 Juli 2026, tetapi tag v2026.7.20 menunjuk commit release yang lebih lama. Pengguna release resmi 0.19.0 belum otomatis mendapat perbaikan hanya dengan menarik image atau package pada tag yang sama.

Siapa yang paling terdampak

Prioritas audit paling tinggi ada pada deployment yang memakai Hermes Agent 0.19.0, Telegram polling mode, dan gateway tanpa synthetic health check. Risiko naik jika koneksi ke api.telegram.org sesekali mengalami timeout, 502, atau network blackhole dan bot dipakai untuk alur pesan yang harus selalu aktif.

Mekanisme fatal handler berada di jalur gateway bersama, jadi hardening upstream dibuat lintas-platform. Namun bukti insiden produksi pada issue ini secara spesifik berasal dari Telegram. Jangan menyimpulkan semua adapter pasti terkena dengan frekuensi yang sama tanpa bukti tambahan.

Mitigasi aman sebelum release berikutnya

Jangan langsung mengambil seluruh branch main ke produksi hanya demi satu patch. Branch pengembangan membawa perubahan lain yang belum dibungkus dalam release stabil.

Untuk operator 0.19.0, langkah sementara yang lebih terukur:

1. jalankan gateway di bawah systemd, launchd, Docker restart policy, atau supervisor setara;
2. pastikan service dapat di-restart otomatis ketika proses keluar failure;
3. tambahkan synthetic check yang menguji jalur pesan, bukan cuma PID dan port;
4. alert jika log fatal adapter tidak diikuti reconnect atau aktivitas polling baru;
5. jika bot diam setelah gangguan jaringan, restart gateway dan verifikasi pesan masuk kembali;
6. pantau release Hermes berikutnya dan pastikan changelog atau commit ancestry memuat 2ab153218.

Untuk deployment Docker, restart policy membantu jika proses benar-benar keluar. Pada release terdampak, bug justru dapat membiarkan proses tetap hidup. Karena itu synthetic message check atau pemeriksaan kesehatan adapter tetap diperlukan.

Cara audit cepat

Mulai dari versi dan log. Pastikan instalasi benar-benar berada pada tag v2026.7.20 atau commit release 3ef6bbd20, lalu cari pola fatal Telegram yang menjadi baris terakhir aktivitas adapter.

Setelah itu cek tiga hal:

• apakah proses gateway masih hidup;
• apakah Telegram masih melakukan polling atau pending update terus bertambah;
• apakah platform masuk antrean reconnect atau hanya tertahan di status retrying.

Jika ketiganya cocok dengan pola issue, lakukan restart terkontrol. Kirim pesan uji setelah service kembali dan pastikan pesan benar-benar diproses. Jangan menganggap restart sukses hanya karena port sudah listening.

Perlu upgrade sekarang?

Belum ada release resmi baru setelah v2026.7.20 saat audit ini dilakukan. Jadi belum ada versi stabil yang bisa direkomendasikan sebagai target upgrade khusus untuk bug tersebut.

Keputusan yang masuk akal adalah mempertahankan 0.19.0 dengan monitoring lebih kuat dan runbook restart, atau menguji patch terisolasi di staging bila Telegram merupakan jalur kritis. Hindari deploy branch main tanpa regression test untuk konfigurasi, session state, dan adapter lain yang dipakai.

Kesimpulan operasional

Bug #74494 mengubah network error sementara menjadi silent outage tanpa batas waktu. Masalah utamanya bukan Telegram sempat gagal, tetapi gateway kehilangan platform dari alur recovery sambil tetap terlihat hidup.

Sampai patch masuk release resmi, anggap process liveness sebagai sinyal yang tidak cukup. Pantau kesehatan adapter, uji jalur pesan end-to-end, dan siapkan restart otomatis serta runbook manual. Saat release berikutnya terbit, verifikasi bahwa patch cancellation-proof benar-benar termasuk sebelum menghapus mitigasi sementara.