Retry ve dead letter · Consumer

Bounded retry haklarını, TTL bucket’larını, jitter ve dead-letter davranışını açıkça yapılandırın.

Retry, handler’ın aynı iş için yeniden çağrılabilmesini sağlar. Uygulama retryable veya permanent sonucunu seçer; bekleme, handoff ve original delivery settlement’ını framework yürütür. Handler içinde sleep ederek bir retry slot’u tutulmaz.

Retry hakkını ve gecikmeyi seçin#

# Fields in the existing orders.created queue entry.
retry_attempts = 3
retry_backoff_millis = 1000
max_retry_backoff_millis = 60000
retry_jitter_ratio = 0.0

retry_attempts=3, ilk işlemden sonra en fazla üç framework retry demektir. Jitter kapalıyken gecikmeler 1000, 2000 ve 4000 ms olur. Exponential backoff üst sınırda durur. Varsayılan retry sayısı 0’dır; bu durumda retryable hata için bile normal failure policy doğrudan dead-letter hedefine gider.

Broker redelivery veya process crash tekrarları bu üç hakla sınırlı değildir. DB transaction replay’i ve outbox relay publish retry da ayrı mekanizmalardır. Bunları tek bir “attempt” sayacı gibi yorumlamayın.

Bekleme broker’daki bucket’ta yapılır#

orders.created
  -> orders.retry.v2
     -> orders.created.retry.v2.1000ms
     -> orders.created.retry.v2.2000ms
     -> orders.created.retry.v2.4000ms
  -> orders.dlx.v2
     -> orders.created.dlq.v2

Bu isimler orders exchange’i ve orders.created queue’su için varsayılan adlardır. Retry queue’ları queue-level TTL sonunda ana route’a döner. Retry kapalıysa retry exchange/bucket declare edilmez. İsimdeki v2 topology formatıdır; mesajın x-lily-schema-version değeri değildir.

Jitter da önceden derlenir#

retry_jitter_ratio finite 0.0..0.5 aralığındadır. Sıfırdan büyükken her nominal gecikme için en fazla lower/nominal/upper bucket hesaplanır; başlangıç ve üst gecikme sınırları korunur. Canonical event ID ve retry attempt sabit hash ile bucket seçer. Aynı gecikmeler tek fiziksel bucket paylaşır.

Bir logical queue en çok 32, bütün topology en çok 4096 distinct retry bucket içerebilir. Yeni queue her mesajda yaratılmaz; arbitrary delay veya delayed-message plugin kullanılmaz. Retry retention hesabı bucket sayısı ile bucket başına kapasitenin çarpımını içermelidir.

Handoff ve taşma davranışı#

Retryable hata ve kalan hak varsa retry bucket’a; permanent hata veya tükenen hak için DLQ’ya mandatory publish yapılır. Broker confirm alınmadan original mesaj ACK edilmez. Handoff hatası/panic/timeout durumunda kalan bütçeyle bir bounded NACK/requeue denenir ve runtime arızası korunur. Settlement belirsiz sonuçları açıklar.

Framework-managed fiziksel queue’lar reject-publish overflow kullanır. Dolu hedefte handoff başarı diye raporlanmaz. Broker’ın TTL/dead-letter transferi için tüm arıza koşullarında end-to-end exactly-once garantisi verilmez.

DLQ inceleme ve replay#

Hazır DLQ replay paneli veya otomatik replay scheduler’ı yoktur. Sebebi inceleyip veriyi/policy’yi düzeltin ve tekrar gönderim kararını uygulama operasyonu olarak verin. Aynı olayın kimliğini korumak için saklanmış event ID kullanın; yeni UUID üretmek transactional deduplication sınırını değiştirir.

x-retry-count yoksa 0 sayılır; varsa AMQP LongInt ve 0..100 olmalıdır. String "0" veya negatif değer canonical değildir. Canonical publisher ve framework handoff bu metadata’yı yönetir; sayaç uygulamanın business attempt kimliği değildir.