Bagaimana webhook yang gagal dicoba ulang, dan apakah event tiba secara berurutan?

Penerima Anda bisa menyimpan event meskipun pengirim tidak pernah menerima acknowledgment-nya. Percobaan ulang karena itu bisa mengulangi pekerjaan yang sudah diterima aplikasi Anda.

Percobaan ulang menunda sebagian event. Event yang lebih baru bisa tiba sebelum percobaan ulang selesai. Simpan identifier event dan waktu kejadian agar pengiriman tersebut tidak menimpa pekerjaan yang lebih baru.

Apa yang dianggap pengiriman gagal?

Bird menganggap pengiriman gagal ketika menerima respons non-sukses atau permintaan kehabisan waktu.

Kembalikan HTTP 2xx setelah menyimpan event untuk menghentikan percobaan ulang pada pengiriman tersebut. Redirect, client error, atau server error tetap layak untuk dicoba ulang.

Misalnya, 400 mencatat permintaan yang ditolak tetapi tidak memberi tahu Bird untuk membuangnya. Gunakan respons error ketika verifikasi tanda tangan atau penyimpanan permanen gagal, agar pengiriman tersebut dapat dipulihkan.

Simpan event sebelum mengirim acknowledgment. Mengembalikan respons sukses lebih dulu dapat kehilangan event jika operasi penyimpanan berikutnya gagal.

Tempatkan pemrosesan yang lambat di background worker agar penerima Anda dapat merespons dengan cepat. Tugas penerima adalah memverifikasi dan menyimpan event sebelum pemrosesan dimulai.

Apa jadwal percobaan ulang?

Bird menggunakan tujuh jeda percobaan ulang setelah percobaan awal, total delapan percobaan.

Jadwal ini memberi Anda sekitar 27,5 jam untuk memperbaiki penerima sebelum percobaan otomatis selesai.

Bird menyesuaikan setiap jeda secara acak hingga 20 persen ke atas atau ke bawah untuk menyebarkan percobaan ulang setelah gangguan. Jeda lima menit karena itu berkisar antara empat hingga enam menit sebelum penyesuaian lainnya.

Respons throttling atau timeout dapat mengubah jeda berikutnya. Bird juga mempertimbangkan Retry-After, header respons yang meminta penundaan sebelum percobaan berikutnya. Perlakukan jadwal ini sebagai jendela pemulihan, bukan tenggat waktu yang pasti.

Setiap percobaan ulang mempertahankan webhook-id event, sehingga penerima Anda dapat mengenali duplikat.

Apa yang terjadi setelah percobaan ulang terakhir?

Percobaan ulang otomatis berhenti untuk pengiriman tersebut. Anda dapat meminta replay pengiriman yang gagal.

Anda meminta pengiriman ulang dengan createWebhookReplay, atau melalui halaman dashboard endpoint. Replay membaca log percobaan pengiriman dan memilih event yang gagal di sana. Event yang Bird tidak pernah dicoba, misalnya event yang tiba saat endpoint dijeda, tidak memiliki percobaan untuk dipilih, sehingga replay tidak dapat memulihkannya.

Responsnya adalah 202, artinya replay diantrikan untuk eksekusi di latar belakang. Respons ini tidak menyertakan jumlah atau identifier tugas. Gunakan listWebhookAttempts untuk memeriksa percobaan berikutnya.

Setiap pengiriman ulang menggunakan satu percobaan, bukan jadwal di atas. Bird mencatat percobaan tersebut dan menyelesaikan tugasnya terlepas dari apakah penerima Anda menerimanya atau tidak. Mengirim ulang ke penerima yang masih rusak hanya membutuhkan satu permintaan per event, bukan delapan. Perbaiki penerima, lalu kirim ulang lagi. Kegagalan tersebut tidak memengaruhi kesehatan endpoint. Pengiriman ulang yang diterima akan menghapus status degradasi.

Replay melewati pengiriman yang sudah berhasil dikonfirmasi. Pengiriman ulang mempertahankan webhook-id aslinya, sehingga penanganan duplikat Anda tetap berlaku.

Tetapkan since dan until sebagai string date-time untuk membatasi jendela pemulihan. Kedua batas bersifat inklusif. Keduanya dibaca berdasarkan waktu percobaan pengiriman, bukan waktu kejadian event. Jika since dihilangkan, jendela dimulai 24 jam sebelum permintaan, sehingga pemadaman yang lebih lama memerlukan waktu mulai yang eksplisit. Jika until dihilangkan, jendela berakhir pada waktu permintaan.

Percobaan disimpan selama tiga hari, yang merupakan batas jangkauan replay. since yang lebih awal memperluas jendela tanpa memulihkan event yang lebih lama. Satu replay juga mencakup paling banyak 10.000 event tertua dalam jendela tersebut, sehingga pemadaman yang lama memerlukan beberapa jendela yang lebih sempit.

Satu organisasi dapat meminta 20 replay per hari UTC. Permintaan selanjutnya menerima 429 dengan WebhookReplayQuotaExceeded, jadi gabungkan pemulihan ke dalam satu jendela alih-alih meminta replay per event.

Bagaimana jika endpoint saya terus gagal?

Bird menandai endpoint yang gagal sebagai terdegradasi. Pengiriman dijeda setelah sekitar lima hari kegagalan tanpa jeda.

Anda dapat membaca status endpoint sebagai active, degraded, atau paused. Endpoint yang terdegradasi tetap menerima pengiriman dan percobaan ulang. Pengiriman yang berhasil menghapus status degradasi dan mengatur ulang penghitung kegagalan berturut-turut.

Endpoint yang dijeda berhenti menerima event dan tidak dilanjutkan secara otomatis. Aktifkan kembali dengan updateWebhook, atur status ke active. Lalu replay jendela waktunya, yang memulihkan pengiriman yang gagal sebelum jeda. Aktifkan kembali terlebih dahulu: replay yang diminta saat endpoint masih dijeda mengembalikan 202 dan tidak mengirim ulang apa pun. Nilai status yang dapat ditulis adalah active dan paused.

Mengubah url penerima atau menyelesaikan pengiriman uji yang berhasil juga menghapus status degradasi. URL pengganti harus dapat dijangkau secara publik HTTPS, sehingga alamat privat tidak dapat memperbaiki keterjangkauan. URL yang lebih panjang dari 2.048 karakter gagal validasi, jadi persingkat URL yang dihasilkan sebelum mengirimkannya.

Mengedit deskripsi endpoint atau langganan event tidak membuktikan bahwa endpoint tersebut dapat menerima permintaan. Perubahan itu tidak menghapus status degradasi, begitu pula pengiriman uji yang gagal.

Bird mengirim email ke pemilik organisasi saat endpoint menjadi terdegradasi. Email degradasi berikutnya tidak dikirim sampai endpoint pulih. Kegagalan berulang karenanya tidak menghasilkan email untuk setiap percobaan. Kegagalan setelah pemulihan memulai periode degradasi baru.

Apakah ada dead-letter queue?

Bird tidak menyediakan antrean terpisah untuk event yang gagal agar Anda baca. Periksa percobaan pengiriman dan minta replay sebagai gantinya.

Perbaiki receiver, aktifkan kembali jika perlu, dan replay jendela yang terpengaruh. Tidak ada antrean terpisah yang perlu dikosongkan setelahnya.

Apakah event tiba berurutan?

Event dapat tiba dalam urutan yang berbeda dari urutan terjadinya.

Event email.delivered dapat tiba sebelum event email.accepted untuk pesan yang sama. Bandingkan waktu event di timestamp sebelum menerapkan perubahan yang akan menimpa status yang lebih baru.

Lacak setiap bagian biaya SMS secara terpisah. Misalnya, biaya pengiriman dan biaya operator adalah komponen biaya yang terpisah.

Objek cost bernilai null sampai sebuah komponen diberi harga. Nilai komponennya berupa string desimal atau null. Field amount adalah string desimal yang menjumlahkan komponen yang ada dalam payload tersebut.

Gabungkan setiap komponen menggunakan timestamp event terbaru. Mengganti seluruh objek dapat menghapus komponen yang diberikan oleh event lain, atau mengembalikan biaya yang lebih lama.

Komponen null berarti komponen tersebut tidak diberi harga dalam payload itu. Bukan berarti biayanya nol. Event SMS menjelaskan penggabungan tersebut dalam konteksnya, dan webhooks membahas semantik pengiriman.