Menangkap Aplikasi yang Crash Tepat Setelah Dipublikasikan

Pada 25 September, tiga publish ditandai berhasil meskipun API aplikasi crash beberapa detik setelah setiap boot. Karena publish itu “berhasil”, rollback tidak berjalan; pemeriksaan latar belakang menggagalkan deployment-nya beberapa menit kemudian, dan seluruh situs menampilkan 404. Health check menghitung crash di daftar event milik platform hosting, yang hanya menyimpan lima event terakhir per mesin, sehingga crash loop membuat daftarnya selalu penuh dan hitungannya tidak pernah bertambah. Sekarang health check membandingkan waktu crash terbaru, dan publish yang mengalami crash loop akan gagal dan memulihkan versi sebelumnya.

Apa yang ditunggu sebuah publish

Ketika Anda mempublikasikan aplikasi dengan backend di Mythex, versi baru digulirkan ke mesin di platform hosting kami, dan health check memutuskan apakah publish itu live atau gagal. Jika gagal, rollback mengembalikan versi sebelumnya.

Bagian yang sulit adalah bahwa “sudah mulai” tidak sama dengan “sedang melayani”. Platform melaporkan mesin sebagai sudah mulai begitu mesin itu naik. Aplikasi yang crash satu detik setelah boot langsung di-restart, dan sesaat kemudian terbaca sudah mulai lagi. Jadi health check telah tumbuh beberapa lapisan dari waktu ke waktu:

1. Lihat dua kali. Setelah mesin terbaca sudah mulai, tunggu sebentar lalu lihat lagi. Crash saat boot sering kali menggagalkan pemeriksaan kedua.
2. Waspadai crash loop. Jika platform melaporkan bahwa sebuah mesin terus crash dan platform berhenti me-restart-nya, gagalkan.
3. Hitung crash sejak publish dimulai. Dua pembacaan “sudah mulai” bisa mencakup sebuah restart di antaranya. Jadi jika ada crash apa pun sejak publish ini dimulai, lihat sekali lagi; jika jumlah crash lebih banyak daripada pada pembacaan sebelumnya, aplikasi tidak tetap berjalan.

Pemeriksaan ketiga itulah yang gagal di sini.

Mengapa hitungannya tetap

Informasi crash berasal dari daftar event setiap mesin: start, exit, restart. Platform hanya menyimpan lima event terakhir per mesin.

Bayangkan sebuah aplikasi yang crash 2,5 detik setelah setiap boot, seperti salah satunya. Setiap siklus menambah satu crash dan satu start. Setelah beberapa siklus, daftarnya penuh. Sejak itu, setiap event baru mendorong keluar event lama. Daftar itu bergeser ke depan, tetapi selalu berisi campuran yang kurang lebih sama: beberapa crash, beberapa start.

Jadi “berapa crash sejak publish dimulai” mengembalikan angka yang sama setiap kali dilihat. Pembacaan kedua melihat, katakanlah, dua crash. Pembacaan ketiga juga melihat dua crash, meski crash-nya berbeda, tetapi jumlahnya sama. Pemeriksaan menyimpulkan bahwa crash sudah berhenti, dan meloloskan publish-nya.

Itu terjadi tiga kali pada 25 September, di dua aplikasi. Setiap kali:

• publish ditandai live,
• tidak ada rollback, karena tidak ada yang dinyatakan gagal,
• reconciler kami, sebuah background job yang memeriksa deployment setelah kejadian, menggagalkan deployment beberapa menit kemudian,
• dan seluruh situs mengembalikan 404.

Publish yang gagal tepat waktu masih bisa dipulihkan: rollback mengembalikan versi sebelumnya. Publish yang gagal beberapa menit terlambat, setelah dinyatakan berhasil, sudah melewatkan rollback-nya.

Bagaimana kami menemukannya

Kami mereproduksinya secara lokal: mengambil API yang berfungsi, membiarkannya tidur, lalu mempublikasikan ulang dengan perubahan yang crash saat boot. Health check menandainya live.

Itu cocok dengan produksi: pada setiap dari tiga publish, aplikasi mati beberapa detik setelah setiap boot, namun jumlah crash yang dibandingkan pemeriksaan tidak pernah naik di antara pembacaan.

Perbaikannya: bandingkan crash terbaru, bukan jumlahnya

Alih-alih menghitung crash, pemeriksaan sekarang melihat waktu crash paling baru sejak publish dimulai.

Jika pembacaan kedua menunjukkan crash apa pun sejak publish dimulai, pemeriksaan menunggu dan melihat sekali lagi. Jika crash terbaru pada pembacaan ketiga lebih baru daripada crash terbaru pada pembacaan kedua, mesin crash lagi di antaranya. Mesin itu tidak tetap berjalan, dan publish gagal dengan pesan bahwa mesin mengalami crash berulang sejak publikasi dan masih terus di-restart.

Ini berfungsi tidak peduli seberapa pendek daftar event-nya. Jendela geser berisi lima event bisa menyembunyikan berapa banyak crash yang terjadi, tetapi tidak bisa menyembunyikan bahwa crash baru baru saja terjadi, karena event terbaru selalu yang tersimpan.

Dengan perubahan ini, reproduksi lokal berperilaku benar: publish gagal, dan image sebelumnya dipulihkan. Ada juga tes yang mensimulasikan perilaku platform, di mana setiap pembacaan menambah satu crash dan satu start dan memangkas daftar menjadi lima, lalu memastikan vonisnya adalah gagal, bukan lolos.

Yang kami pelajari

• Ketahui bentuk data yang Anda hitung. Hitungan di atas daftar yang dibatasi kehilangan maknanya begitu daftarnya penuh. Batasnya tidak tersembunyi; kami hanya belum merancang pemeriksaan di sekitarnya.
• Lebih baik bertanya “apakah ada yang baru terjadi?” daripada “berapa banyak yang terjadi?” Timestamp terbaru bertahan setelah pemangkasan. Total tidak.
• Kegagalan yang terlambat lebih buruk daripada yang lebih awal. Build yang rusak sama sekali tidak berbahaya jika publish gagal dan di-rollback, tetapi bisa menjatuhkan situs jika lebih dulu dinyatakan berhasil.
• Reproduksi dengan kondisi nyata. Bug ini butuh mesin yang sudah crash cukup banyak kali sampai daftar event-nya penuh. Satu crash cepat dalam tes tidak akan menunjukkannya.

Perbaikan ini berpasangan dengan perbaikan lain dari hari yang sama, yang memastikan rollback mengembalikan versi lama alih-alih menghapusnya: republish yang gagal tidak pernah menghapus backend yang berfungsi. Jika aplikasi Anda sendiri gagal dipublikasikan karena crash saat start, dokumentasi pemecahan masalah publish dan panduan kami tentang men-debug aplikasi yang dibuat dengan AI adalah tempat yang baik untuk memulai.