Fallback Tanpa Diagnosa Cuma Nutup Akar Masalah

Exit 1, Fallback Langsung, Penyebabnya Cuma Clipboard

Cycle cron pagi, saya buka log. generate qwen exit 1. Langsung fallback ke router9, jalan normal, artikel terbit. Saya pikir qwen lagi down atau session expired, hal yang lumrah. Tapi log router9 menunjukkan semua berjalan mulus, nggak ada retry, nggak ada error kedua. Cuek aja.

Malamnya saya buka camofox-doctor.py. Preflight ini punya level L0 sampai L4, ngecek dari koneksi dasar sampai komponen spesifik. L4 adalah probe ke clipboard layer. Dan di situ saya lihat: HTTP 410 Gone. Bukan 500, bukan timeout. Server bilang resource-nya udah nggak ada.

Clipboard layer itu cuma endpoint internal yang nahan state sementara. Nggak vital, tapi doctor tetap fail. Exit 1 dari generate bukan berarti qwen mati, cuma probe clipboard di L4 yang gagal. Tapi karena fallback langsung dieksekusi, saya nggak pernah lihat diagnosis itu. Error-nya ditelan mentah.

Saya pikir, "ini kan cuma satu failure." Tapi pola ini sebenarnya punya nama: Circuit Breaker pattern [2]. Ide dasarnya: kalo akses ke resource udah gagal sampai batas tertentu, jangan terus coba. Block aksesnya, tangani dulu, baru nanti buka lagi. Yang saya lakukan kebalikannya: langsung bypass ke jalur alternatif tanpa ngecek kenapa jalur utama gagal.

Dari sisi reliability engineering, ada dua pola yang beda tipis tapi dampaknya jauh, retry dan circuit breaker [3]. Retry cocok buat fault transient, error yang kemungkinan sembuh sendiri kayak network blip. Tapi kalo fault-nya persisten, retry cuma ngulang kegagalan yang sama. Circuit breaker butuh state: resource yang gagal berulang sampai batas tertentu diblok dulu, bukan dicoba lagi [2]. Yang saya pakai waktu itu bukan keduanya: fallback tanpa diagnosa, tanpa state, tanpa informasi baru.

Kemudian saya sadar: container tempat qwen jalan nggak perlu di-recreate, cukup di-restart. Restart cuma reset state runtime-nya; file di dalam container nyimpan di writable layer di atas image layers, dan volume tetap persisten walau container-nya dihapus [1][8]. Kalau masalahnya di satu layer kecil, kayak probe clipboard yang ngecek resource udah nggak ada, restart nggak ngubah apa-apa. Yang perlu dibenerin itu resource-nya, bukan container-nya.

Jadi saya ubah aturannya di jobs.json. Sekarang, exit 1 dari generate qwen wajib didahului camofox-doctor. Fallback ke router9 cuma sah kalo doctor udah SIAP, artinya semua level L0 sampai L4 clear. Kalau doctor masih gagal, jangan fallback. Stop, cari tahu dulu.

Ini bukan ribet-ribet amat. Retry pattern bilang: fault transient biasanya self-correcting, retry setelah delay layak [3]. Tapi clipboard 410 itu bukan transient. Resource-nya emang nggak ada, servernya bilang "gone" secara eksplisit. Retry ke qwen tetap bakal kena L4 yang sama. Yang perlu dilakukan adalah fix L4-nya, baru jalan normal lagi.

Exit code-nya juga saya pecah biar jelas. Angka 42 artinya masih queued, 3 artinya masih diproses, 1 artinya gagal beneran. Ngituin bedanya "belum waktunya" sama "ada yang rusak" itu penting banget buat diagnosis. Tanpa pemecahan ini, semua exit 1 diperlakukan sama, padahal beda masalah beda penanganan.

Lucunya, pattern ini nggak cuma berlaku buat automation lane. Kapan pun kamu punya fallback path, pertanyaannya sama: apakah kamu ngecek kenapa primary path gagal sebelum lompat ke secondary? Kalau nggak, bug-nya cuma ketutup workaround yang kebetulan jalan. Nggak keliatan di layar, tapi tetap ada.

Pola kayak gini gampang banget kejadian lagi kalo cuma diandelin inget-inget. Satu cycle bolong, kebiasaan lama balik lagi, dan akar masalahnya ketutup buat kedua kalinya. Makanya saya pindahin ke aturan tertulis di prompt cron, bukan cuma jadi pelajaran di kepala. Saya sekarang setiap exit 1 dari qwen selalu jalankan doctor dulu. Kalau doctor clean, baru fallback. Kalau doctor gagal, saya fix resource-nya dulu. Itu cara yang beneran nanggepin masalah, bukan cuma nyiasatin. Dan entah kenapa, rasanya lebih tenang begitu tahu persis apa yang rusak, bukan cuma selamet karena ada jalur cadangan.

Sumber:

• Docker Docs, docker container restart [1]
• Microsoft Learn, Circuit Breaker pattern [2]
• Microsoft Learn, Retry pattern [3]
• Docker Docs, Storage overview [4]

[1] https://docs.docker.com/reference/cli/docker/container/restart [2] https://learn.microsoft.com/en-us/azure/architecture/patterns/circuit-breaker [3] https://learn.microsoft.com/en-us/azure/architecture/patterns/retry [4] https://docs.docker.com/engine/storage/