Warning OpenClaw 2026.4.29: Bisa Crash-Loop Saat Restart dan Turn Jadi Lambat Parah

Kalau Anda cuma butuh verdict singkat: jangan blind upgrade ke OpenClaw 2026.4.29 di host produksi yang mirip dengan environment ini.

Pada 1 Mei 2026 WIB, saya uji upgrade live dari OpenClaw 2026.4.26 ke 2026.4.29 di host operasional berbasis OpenCloudOS 9. Paket baru memang berhasil terpasang. Tapi begitu gateway direstart, saya kena dua masalah berurutan:

1. gateway crash-loop karena validasi config baru;
2. setelah config diperbaiki dan gateway bisa hidup, latency turn melonjak parah sampai tidak layak dipertahankan di production.

Akhirnya versi ini saya rollback lagi ke 2026.4.26.

Ringkasan cepat

• Upgrade diuji pada Jumat, 1 Mei 2026.
• Jalur upgrade aman sudah dipakai: baseline check, backup package+config, install versi baru, restart, lalu smoke test.
• Crash-loop pertama muncul karena schema config di 2026.4.29 menolak konfigurasi web search yang sebelumnya masih lolos di 2026.4.26.
• Setelah config diperbaiki, gateway bisa start, Telegram tetap connected, tetapi runtime melambat berat.
• Smoke test sederhana yang hanya meminta balasan exact string memakan waktu 63.235 ms.
• Log liveness menunjukkan event loop delay sampai 53.586,4 ms.
• Trace persiapan turn sempat tembus 82.437 ms sebelum model mulai benar-benar jalan.
• Keputusan final: rollback ke 2026.4.26. Setelah rollback, smoke test turun lagi ke 19.696 ms dan Telegram probe kembali normal.

Masalah pertama: restart awal langsung crash-loop

Setelah npm install -g [email protected], restart gateway pertama dilakukan pada 1 Mei 2026 sekitar 15:46 WIB.

Yang terjadi bukan sekadar restart lama. Gateway masuk crash-loop karena validasi config gagal dengan pesan inti seperti ini:

Invalid config at /root/.openclaw/openclaw.json:
- tools.web.search.openaiCodex.userLocation.region: Invalid input: expected nonoptional, received undefined

Artinya jelas: di versi ini, field region pada blok berikut menjadi wajib untuk config tertentu:

• tools.web.search.openaiCodex.userLocation.country
• tools.web.search.openaiCodex.userLocation.city
• tools.web.search.openaiCodex.userLocation.timezone
• tools.web.search.openaiCodex.userLocation.region

Di host ini, config lama hanya berisi country, city, dan timezone. Pada 2026.4.26 itu masih jalan. Pada 2026.4.29, gateway menolak start sampai field region ditambahkan.

Perbaikan sementara yang saya pakai:

"tools": {
 "web": {
 "search": {
 "openaiCodex": {
 "userLocation": {
 "country": "ID",
 "city": "Jakarta",
 "timezone": "Asia/Jakarta",
 "region": "Jakarta"
 }
 }
 }
 }
}

Sesudah patch itu, gateway akhirnya bisa naik lagi. Jadi kalau Anda upgrade ke 2026.4.29 dan gateway mendadak tidak mau start, cek blok userLocation ini dulu.

Masalah kedua: gateway hidup, tapi turn jadi sangat lambat

Setelah config diperbaiki, gateway berhasil start ulang pada 1 Mei 2026 sekitar 18:26 WIB. Sekilas terlihat sehat:

• service systemd aktif,
• gateway reachable,
• Telegram probe bilang connected,
• bot masih bisa terhubung.

Masalahnya, sehat di status belum tentu sehat di runtime.

Begitu saya jalankan smoke test sederhana, performanya jatuh jauh dari normal.

Evidence yang muncul di host ini

Smoke test pasca-fix ke 2026.4.29:

• prompt: minta balasan exact string OC_SMOKE_OK_429
• hasil: sukses menjawab
• durasi total: 63.235 ms

Padahal setelah rollback ke 2026.4.26, smoke test setara turun ke:

• OC_SMOKE_OK_426_POST
• durasi total: 19.696 ms

Jadi masalahnya bukan sekadar "masih bisa menjawab". Masalahnya adalah waktu tunggu naik terlalu jauh untuk channel operasional.

Log yang paling mengkhawatirkan

Pada 1 Mei 2026 18:31 WIB, log gateway mengeluarkan warning liveness seperti ini:

liveness warning: reasons=event_loop_delay,event_loop_utilization interval=58s eventLoopDelayP99Ms=53586.4 eventLoopDelayMaxMs=53586.4 eventLoopUtilization=1

Lalu trace persiapan turn yang sama menunjukkan:

phase=stream-ready totalMs=82437
core-plugin-tools:15347ms
system-prompt:56159ms
stream-setup:7252ms

Ada juga percobaan lain yang masih jelek walau lebih rendah:

phase=stream-ready totalMs=32795
core-plugin-tools:16586ms
system-prompt:5755ms
stream-setup:6845ms

Buat operator, arti praktisnya simpel:

• event loop sempat tertahan sangat lama,
• setup turn memakan waktu tidak wajar,
• Telegram mulai kena efek samping seperti sendChatAction failed, handshake timeout, dan connect timeout,
• walau bot belum benar-benar "mati", responsnya sudah terlalu lambat untuk dipakai nyaman.

Gejala yang terlihat di Telegram

Saat 2026.4.29 masih aktif, saya melihat kombinasi gejala berikut di log:

• fetch timeout reached; aborting operation
• sendChatAction failed
• gateway request timeout for connect
• handshake timeout
• typing TTL reached

Ini penting karena banyak operator cuma cek satu hal: "bot masih connected atau tidak". Di kasus ini, Telegram memang masih connected, tapi pengalaman pakainya sudah turun jauh.

Jadi kalau setelah upgrade Anda melihat bot masih hidup tapi terasa "berat", "lama mikir", atau typing-nya aneh, jangan buru-buru menyalahkan provider model dulu. Gateway/runtime-nya sendiri bisa lagi seret.

Issue upstream yang bikin warning ini makin relevan

Kasus host ini bukan muncul di ruang kosong. Pada 1 Mei 2026, sudah ada beberapa issue upstream yang sangat relevan dengan pola ini.

1. Issue #75539

Telegram/QQBot plugins fail to connect on servers without global IPv6

Intinya, ada laporan bahwa di 2026.4.29, kombinasi undici + environment tanpa global IPv6 bisa bikin koneksi plugin tertentu jadi macet atau timeout. Workaround yang disarankan adalah memaksa IPv4-first.

Di host ini saya memang sudah menambahkan guard systemd:

Environment="NODE_OPTIONS=--dns-result-order=ipv4first"

Itu membantu, tapi tidak cukup menyelesaikan seluruh masalah latency yang muncul setelah upgrade.

2. Issue #75428

Answer question too slow when update to 4.29

Ini selaras dengan gejala live yang saya lihat sendiri: bot masih jalan, tapi turn jadi lambat sekali.

3. Issue #75512

Chat-turn latency 30-60s+ on every turn since v2026.4.23

Issue ini bicara soal evaluasi runtime/plugin per turn yang terlalu berat. Dari log host ini, area seperti core-plugin-tools, model-resolution, auth, dan system-prompt memang terlihat makan waktu besar.

4. Issue #74860 dan #75122

Dua issue ini sama-sama menyorot event-loop stall dan dampaknya ke channel/runtime. Polanya tidak identik 100%, tapi secara operasional warning-nya sama: ketika event loop tersendat lama, channel bisa tetap terlihat hidup sambil pengalaman pakainya runtuh.

Apa yang saya lakukan untuk memulihkan server

Keputusan akhirnya bukan mencoba menambal lebih jauh di atas 2026.4.29. Untuk server produksi, saya pilih langkah yang lebih waras:

1. simpan evidence log dan snapshot baseline,
2. catat error install/restart/config,
3. rollback package global ke 2026.4.26,
4. restart gateway,
5. verifikasi lagi versi, gateway, Telegram probe, dan smoke test.

Hasil setelah rollback:

• openclaw --version kembali ke 2026.4.26 (be8c246),
• gateway running,
• Telegram probe kembali works,
• smoke test OC_SMOKE_OK_426_POST selesai dalam 19.696 ms.

Buat saya, itu cukup untuk menutup keputusan: 2026.4.29 belum layak dipertahankan di host ini.

Kalau Anda sudah terlanjur upgrade, cek ini dulu

Kalau Anda baru naik ke 2026.4.29 dan mulai merasa ada yang aneh, urutan cek praktisnya seperti ini:

openclaw --version
openclaw gateway status
openclaw channels status --probe --timeout 30000
openclaw gateway stability
journalctl -u openclaw-gateway.service -n 200 --no-pager

Lalu fokus ke tiga hal:

1. apakah config baru menolak gateway saat startup;
2. apakah log liveness memunculkan event-loop delay besar;
3. apakah smoke test sederhana mendadak jauh lebih lama dari baseline versi sebelumnya.

Kalau ketiganya kena, jangan paksakan tetap di 2026.4.29 hanya karena bot masih menjawab.

Perlu rollback atau cukup tunggu patch?

Kalau environment Anda mirip host ini -- VPS cloud, Telegram aktif, tidak punya global IPv6 penuh, dan dipakai untuk operasional harian -- saya cenderung bilang:

• jangan upgrade blind ke 2026.4.29 dulu, atau
• kalau sudah upgrade dan gejalanya sama, rollback itu keputusan yang masuk akal.

Kalau Anda punya staging server sendiri, silakan uji dulu. Tapi untuk production yang sensitif terhadap respons channel, saya lebih percaya hasil live host ini daripada asumsi bahwa semua stable release pasti aman.

Kesimpulan

OpenClaw 2026.4.29 membawa changelog yang besar dan menarik. Tapi di host ini, realitanya sederhana:

• update berhasil terpasang,
• restart pertama crash-loop karena config schema baru,
• setelah fix config, gateway hidup tapi latency-nya terlalu parah,
• akhirnya rollback ke 2026.4.26.

Jadi kalau Anda cari jawaban singkat: ya, issue 2026.4.29 ini cukup serius untuk dijadikan warning terpisah.

Dan kalau gejala Anda mirip dengan yang saya tulis di atas, jangan buang waktu terlalu lama menebak-nebak. Ambil log, ukur delay, lalu putuskan cepat apakah mau patch lanjut atau rollback.