Karakteristik percobaan ulang Eventarc cocok dengan karakteristik lapisan transpornya, Cloud Pub/Sub. Untuk informasi selengkapnya, lihat Mencoba ulang permintaan dan Penundaan push.
Durasi retensi pesan default yang ditetapkan oleh Eventarc adalah 24 jam dengan penundaan backoff eksponensial.
Anda dapat memperbarui kebijakan percobaan ulang melalui langganan Pub/Sub yang terkait dengan pemicu Eventarc:
- Buka halaman detail Pemicu.
- Klik topik.
- Klik tab Langganan.
Setiap langganan yang dibuat secara otomatis oleh Eventarc akan memiliki format ini: projects/PROJECT_ID/subscriptions/eventarc-REGION-TRIGGER_ID-sub-SUBSCRIPTION_ID. Untuk mengetahui informasi selengkapnya tentang batas langganan, lihat Batas resource Pub/Sub.
Jika Pub/Sub mencoba mengirimkan pesan, tetapi tujuannya tidak dapat mengonfirmasinya, Pub/Sub akan mengirim pesan lagi dengan backoff eksponensial minimum 10 detik. Jika tujuan terus tidak mengonfirmasi pesan, lebih banyak waktu akan ditambahkan ke penundaan di setiap percobaan ulang (maksimal 600 detik) dan pesan akan dikirim ulang ke tujuan.
Perhatikan bahwa Alur Kerja mengonfirmasi peristiwa segera setelah eksekusi alur kerja dimulai.
Topik yang dihentikan pengirimannya
Jika tujuan tidak menerima pesan, Anda dapat meneruskan pesan yang tidak terkirim ke topik yang dihentikan pengirimannya (juga dikenal sebagai antrean yang dihentikan pengirimannya). Topik dead-letter dapat menyimpan pesan yang tidak dapat dikonfirmasi oleh tujuan. Anda harus menetapkan topik dead-letter saat membuat atau memperbarui langganan Pub/Sub, bukan saat membuat topik Pub/Sub atau saat Eventarc membuat topik Pub/Sub. Untuk mengetahui informasi selengkapnya, lihat Menangani kegagalan pesan.
Error yang tidak menjamin percobaan ulang
Jika aplikasi menggunakan Pub/Sub sebagai sumber peristiwa dan peristiwa tersebut tidak dikirim, peristiwa akan otomatis dicoba ulang, kecuali untuk error yang tidak menjamin percobaan ulang. Peristiwa ke tujuan alur kerja dari sumber apa pun tidak akan dicoba lagi jika alur kerja tidak dijalankan. Jika eksekusi alur kerja dimulai, tetapi kemudian gagal, eksekusi tidak akan dicoba ulang. Untuk menyelesaikan masalah layanan tersebut, Anda harus menangani error dan percobaan ulang dalam alur kerja.
Acara duplikat
Peristiwa duplikat mungkin dikirim ke pengendali peristiwa. Menurut
spesifikasi CloudEvents,
kombinasi atribut source dan id dianggap unik, dan
karenanya setiap peristiwa dengan kombinasi yang sama dianggap duplikat.
Anda harus menerapkan pengendali peristiwa
idempotent sebagai praktik terbaik umum.
Membuat pengendali peristiwa bersifat idempoten
Pengendali peristiwa yang dapat dicoba ulang harus bersifat idempoten, menggunakan panduan umum berikut:
- Banyak API eksternal yang dapat Anda gunakan untuk menyuplai kunci idempotensi sebagai parameter. Jika menggunakan API seperti itu, Anda harus menggunakan ID peristiwa sebagai kunci idempotensi.
- Idempotensi berfungsi dengan baik pada pengiriman "setidaknya sekali" karena memberikan keamanan untuk mencoba ulang. Jadi, salah satu praktik terbaik yang umum untuk menulis kode tepercaya adalah dengan menggabungkan idempotensi dengan percobaan ulang.
- Pastikan kode Anda idempoten secara internal. Contoh:
- Pastikan mutasi bisa terjadi lebih dari sekali tanpa mengubah hasilnya.
- Jalankan kueri pada status database dalam transaksi sebelum memutasikan status tersebut.
- Pastikan semua efek samping bersifat idempoten.
- Lakukan pemeriksaan transaksi di luar layanan Anda, terlepas dari kode. Sebagai contoh, pertahankan status di suatu tempat yang mencatat bahwa ID peristiwa tertentu telah diproses.
- Tangani panggilan duplikat yang tidak umum. Misalnya, jalankan proses pembersihan terpisah yang akan melakukan pembersihan setelah panggilan duplikat.