Follow-up from PR #177 review.
The news consumer uses message.redelivered as its retry signal. Because the queue is producer-owned and declared passively, redelivered is the only signal available. The consequence: any broker/connection blip that redelivers an in-flight message dead-letters it on the next delivery instead of retrying, and a DB outage longer than one attempt cycle dead-letters the whole in-flight window (the DLQ is drop-head bounded, so a sustained outage can shed articles).
Upgrade path once the producer adopts it:
- a quorum queue exposing
x-delivery-count, or
- a producer-incremented retry-count header, giving real "retry N times" semantics.
Requires coordination with the news (producer) service, which owns the queue topology.
Follow-up from PR #177 review.
The news consumer uses
message.redeliveredas its retry signal. Because the queue is producer-owned and declared passively,redeliveredis the only signal available. The consequence: any broker/connection blip that redelivers an in-flight message dead-letters it on the next delivery instead of retrying, and a DB outage longer than one attempt cycle dead-letters the whole in-flight window (the DLQ is drop-head bounded, so a sustained outage can shed articles).Upgrade path once the producer adopts it:
x-delivery-count, orRequires coordination with the news (producer) service, which owns the queue topology.