Transactional inbox · Consumer

Inbox kimliği, atomik DB kapsamı ve startup koşullarıyla yinelenen mesajları yönetin.

Transactional inbox, aynı handler için daha önce tamamlanmış bir event’in iş kodunu tekrar çalıştırmasını engeller. Lily inbox kaydını, işlem boyunca yapılan uygun DB yazılarını ve outbox eklemelerini aynı veritabanı transaction’ında tamamlar. RabbitMQ ACK işlemi bu commit’in sonrasındadır.

Dört parça birlikte etkinleşir#

PostgreSQL veya MongoDB için ilgili consumer-transactional-inbox-* facade feature’ını seçin.
Handler’a delivery_guarantee = "transactional_inbox" ekleyin.
Physical queue’nun transactional_inbox bölümünde backend’i ve factory kullanıyorsanız cell’i açıkça belirtin.
Consumer’ı başlatmadan önce seçilen veritabanında Lily component migration’ını uygulayın.

#[queue("orders.created", version = 1, content = "json", delivery_guarantee = "transactional_inbox")]

Bu satır tek başına bir uygulama değildir; #[queue_service] ile tanımlanmış handler metodunun attribute’udur. Tam kod ve manifest için PostgreSQL veya MongoDB sayfasını izleyin. Son #[queue] argümanından sonra virgül bırakmayın.

Inbox anahtarı ve saklama süresi#

Deduplication anahtarı, üretilmiş handler kimliği ile canonical event ID’nin birleşimidir. Handler kimliği module path, servis tipi ve metot adından türetilir. Schema version veya content kind ayrı bir inbox anahtarı alanı değildir. Servisi yeniden adlandırmak, başka module’a taşımak veya crate yolunu değiştirmek yeni bir deduplication alanı oluşturabilir.

Tamamlanmış inbox kaydı bulunursa iş pipeline’ı atlanır ve delivery başarılı settlement yoluna gider. inbox_retention_secs nedeniyle bu kayıt temizlendikten sonra aynı eski event yeniden işlenebilir. Event replay politikanız, deploy sırasında handler kimliği değişiklikleri ve retention süresi birlikte tasarlanmalıdır.

Garanti hangi işlemleri kapsar?#

Kapsam içinde	Kapsam dışında
Inbox claim ve completion	RabbitMQ ACK
Verilen transaction context’i kullanan aynı DB yazıları	Başka havuz, cell veya session üzerinden yapılan yazılar
Aynı transaction’a eklenen outbox kayıtları	Relay’in broker publish işlemi
Commit öncesi rollback edilen DB değişiklikleri	HTTP, e-posta, dosya ve Redis yan etkileri

Bu sözleşme uçtan uca exactly-once veya broker–DB arasında two-phase commit değildir. Commit başarılı, ACK başarısız olabilir; sonraki delivery inbox üzerinden tanınır. Relay publish başarılı, delivered işareti başarısız olabilir; downstream aynı outbox event ID’sini yeniden görebilir.

Startup ve backend farkları#

Feature, handler metadata’sı ve fiziksel queue binding’i uyuşmazsa startup başarısız olur. Transactional handler bulunmayan queue’ya bırakılmış eski binding de reddedilir. Backend otomatik seçilmez ve at-least-once’a sessiz fallback yapılmaz. Aynı physical queue’nun farklı version/content handler’ları iki guarantee modunu birlikte kullanabilir; transactional olanlar o queue’nun tek storage binding’ini paylaşır.

PostgreSQL eşzamanlı duplicate için retryable hata üretir ve normal retry/DLQ politikasını kullanır. MongoDB lease contention’ı original delivery’yi yeniden queue’ya bırakabilir; belirli transient transaction hatalarında ise bütün pipeline’ı yeni scope ile replay eder. İki backend’in retry davranışını aynı kabul etmeyin. Backend sayfaları ve sınırlar hangi durumun hangi bütçeyi kullandığını açıklar.