Sorun giderme · Consumer

Startup, delivery ve transaction sorunlarını teşhis edin; kaynak belgelerindeki dört çelişkiyi görün.

Önce hatanın compile-time, startup, delivery, settlement veya shutdown aşamasında mı oluştuğunu belirleyin. ConsumerError typed nedenleri taşır; lifecycle failure birincil hata ile cleanup sırasında oluşan ikincil evidence’ı birlikte koruyabilir. Görünen son cleanup hatasını bütün sorunun ilk nedeni saymayın.

Startup başlamıyor#

Belirti	Kontrol edilecek alan
Handler bulunamadı veya duplicate contract	Binary’ye bağlı modül, queue adı ve `(version, content)` anahtarı; configured queue boş bırakılamaz.
Unknown TOML field	Eski queue section’ı, yanlış alan adı veya feature kapalıyken transactional binding.
Retention/topology hatası	Altı retention alanı, external DLX/routing key, exclusive=false ve derived identity sınırları.
Bağlantı planı reddedildi	Explicit use_tls, URI scheme, URI ile ayrı connection alanlarının karışmaması.
Transactional preflight hatası	Feature, backend, single/factory cell, migration ve gerçek schema/index sözleşmesi.
Mongo transaction desteklenmiyor	Standalone yerine transaction-capable replica set veya sharded deployment.

Preflight hatalarını çözmek için runtime source’undaki __private prepare fonksiyonlarını çağırmayın. Public migrator’ı doğru DB cell’ine uygulayın ve normal startup’ı yeniden deneyin. Lily migration’ı startup içinde otomatik çalıştırmaz; version marker’ını elle değiştirerek schema kontrolünü geçmeye çalışmayın.

Mesaj geliyor ama handler çalışmıyor#

Canonical event ID, pozitif schema version ve content-kind header’larını kontrol edin; header’sız V1/JSON fallback yoktur. Sonra queue’nun linked version/content contract’ını, payload boyutunu, extractor/validation sonucunu ve guard kararını inceleyin. Transactional inbox’ta AlreadyCompleted, iş kodunu bilerek atlayan başarılı bir deduplication sonucudur.

Aynı queue’yu paylaşan replica’lar farklı contract set’leri destekliyorsa RabbitMQ doğru binary’yi version header’a göre seçmez. Incompatible rollout için ayrı physical queue veya binding planlayın. Bu durum local dispatch tablosuna başka handler ekleyerek bütün cluster için otomatik çözülmez.

Retry, duplicate ve outbox soruları#

Durum	Kaynağa göre yorum
PostgreSQL duplicate hemen DLQ’ya gidiyor	`InProgress` normal retryable yoldadır; retry_attempts=0 seçimini kontrol edin.
Mongo handler bir delivery içinde tekrar çalışıyor	TransientTransactionError bütün pipeline’ı fresh scope ile replay edebilir.
Mongo requeue application retry sayısını artırmıyor	Lease contention/ambiguous commit özel original-requeue yolları olabilir.
Outbox kayıt var fakat publish yok	Destination routing, confirm hatası, claim lease, attempt exhaustion ve terminal runtime sonucunu kontrol edin.
Aynı outbox event’i iki kez geldi	Confirm sonrası delivered işareti öncesi crash penceresi mümkündür; downstream deduplication gerekir.
Aynı cell için policy conflict	Yalnız relay alanları değil bütün TransactionalInboxConfig eşit olmalıdır.

Outbox attempt exhaustion kaydı silmez; terminal relay failure Consumer lifecycle’ına taşınır. Public bir retry-reset API’si varmış gibi SQL veya collection alanlarını rastgele değiştirmeyin. Önce failure evidence’ını ve işinizin replay/idempotency politikasını inceleyin. Cleanup yalnız completed inbox ve delivered outbox retention’ını uygular.

C01 — #[queue] son argüman virgülü#

İncelenen source commit’i 78ca08b822aa192623c7bcffd90edaf06e4f8e55 için macro rustdoc ilk örneği ve transactional örneği son argümandan sonra virgül gösterir. Gerçek parser bunu trailing comma is not accepted in #[queue] hatasıyla reddeder.

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

Bu sitedeki örnekler son macro argümanını virgülsüz yazar. Yayımlanmış facade ile yapılan negatif kontrol de virgüllü varyantın beklenen compile error ürettiğini doğruladı. Normal Rust fonksiyon parametrelerinde trailing comma kullanımı bu macro parser kuralından farklıdır.

C02 — Deadline ve cancellation sırası#

QUEUE_MACROS.md ve Consumer configuration rehberi, stage cutoff/ikinci middleware reserve veya handler drop’tan sonra cancellation anlatan eski ifadeler içerir. Budget kaynağı, pipeline ve cooperative execution esas alınır.

Güncel davranış: normal pipeline tek cutoff ve ortak bounded reserve kullanır. Önce cancellation sinyali verilir, normal execution sınırlı cooperation süresince poll edilir ve gerekirse sonra düşürülür. Owner cleanup kalan deadline içinde yürütülür; tamamlanma kanıtı eksikse bu durum raporda korunur. Normal after callback için ikinci bağımsız timeout başlamaz. Deadline rehberi bu modeli kullanır.

C03 — Pending DI rollback bütçesi#

Consumer README, pending DI build için bağımsız rollback bütçesinden Consumer bütçesine geçildiği izlenimini verir. Build transaction DI rollback timeout’unu Consumer timeout’u ile sınırlar ve mevcut rollback başlangıcını aynı attempt root’una taşır. Güncel LIFECYCLE sözleşmesi bu sahipliği açıklar.

Bu nedenle pending DI rollback, Consumer shutdown’a koşulsuz ek 30 saniye kazandırmaz. Configuration henüz çözülmediyse fallback budget kullanılabilir; bu yeni ve sınırsız bağımsız cleanup owner’ı anlamına gelmez. Aynı attempt’in bounded receipt/evidence zinciri korunur.

C04 — Force notification ve settlement revocation#

Queue ARCHITECTURE, force reserve başlarken settlement authority’nin hemen iptal edildiği izlenimini verir. Gerçekte force_drain önce execution’a sinyal verir ve admission’ı kapatır; final forced cutoff sonrasında authority revoke ve abort uygulanır.

Sağlıklı channel cooperative pencerede settlement yapabilir. Transport kaybında eski generation’ın yetkisinin hemen kesilmesi farklı bir durumdur. Force notification, final revocation ve gerçek resource termination aynı olay gibi raporlanmamalıdır. Shutdown ve settlement sayfaları bu ayrımı korur.

Tanı verisini doğru yorumlayın#

Bu dört kayıt, incelenen commit’te belge ile source arasındaki doğrudan farklardır; framework dosyaları bu dokümantasyon çalışmasında değiştirilmedi. Yeni bir sürüme geçerken bu kayıtları yeniden source ile karşılaştırın. Sayfalarda source esas alınmıştır; eski prose otomatik olarak güncel davranış kabul edilmez.

Aggregate snapshot canlılık/readiness durumunu, shutdown report ise action ve termination evidence’ını gösterir. Bunları uygulamanızın error code ve sınırlandırılmış log’larıyla birlikte inceleyin. Snapshot’a payload, broker URI veya terminal-observation event ID listesini sessizce eklemeyin; dışarı sunduğunuz tanı yüzeyini uygulama olarak siz seçersiniz.