Summary
Generalize native dead-letter-queue → durable-storage recovery beyond RabbitMQ, with consistent syntax, so Amazon SQS / Azure Service Bus (and other native-DLQ transports) can forward natively dead-lettered messages into the Wolverine durable message store.
Today
RabbitMQ has a first-class bridge: EnableDeadLetterQueueRecovery() registers DeadLetterQueueListener (a hosted service) that consumes the native DLQ, reconstructs the Envelope from x-death metadata, and calls IMessageInbox.MoveToDeadLetterStorageAsync(...) — so native dead letters land in wolverine_dead_letters and are queryable/replayable via IDeadLetters.
Amazon SQS and Azure Service Bus have no equivalent. Propagating their native DLQ messages into durable storage is a DIY pattern: a listener on the native DLQ + a handler that reconstructs the envelope and calls MoveToDeadLetterStorageAsync. Each transport's native dead-letter metadata differs (SQS attributes/redrive; ASB DeadLetterReason/DeadLetterErrorDescription on the $DeadLetterQueue sub-queue).
Ask
A first-class recovery feature for native-DLQ transports with similar syntax to RabbitMQ's EnableDeadLetterQueueRecovery() (on the SQS / ASB transport expressions) that consumes the native DLQ, reconstructs the Envelope from the transport's native dead-letter metadata, and persists via MoveToDeadLetterStorageAsync.
Why
Tools that manage the durable DLQ (e.g. CritterWatch) can only see/replay messages in the durable store — native-DLQ messages are invisible without this bridge. Today only RabbitMQ users get it out of the box. A consistent, built-in feature makes "make my native dead letters manageable" a one-call decision on every transport.
Pairs with
A queryable per-endpoint dead-letter-destination contract (filed separately) so monitors can detect un-bridged native DLQs and recommend enabling this.
Context: JasperFx/CritterWatch#351.
Summary
Generalize native dead-letter-queue → durable-storage recovery beyond RabbitMQ, with consistent syntax, so Amazon SQS / Azure Service Bus (and other native-DLQ transports) can forward natively dead-lettered messages into the Wolverine durable message store.
Today
RabbitMQ has a first-class bridge:
EnableDeadLetterQueueRecovery()registersDeadLetterQueueListener(a hosted service) that consumes the native DLQ, reconstructs theEnvelopefromx-deathmetadata, and callsIMessageInbox.MoveToDeadLetterStorageAsync(...)— so native dead letters land inwolverine_dead_lettersand are queryable/replayable viaIDeadLetters.Amazon SQS and Azure Service Bus have no equivalent. Propagating their native DLQ messages into durable storage is a DIY pattern: a listener on the native DLQ + a handler that reconstructs the envelope and calls
MoveToDeadLetterStorageAsync. Each transport's native dead-letter metadata differs (SQS attributes/redrive; ASBDeadLetterReason/DeadLetterErrorDescriptionon the$DeadLetterQueuesub-queue).Ask
A first-class recovery feature for native-DLQ transports with similar syntax to RabbitMQ's
EnableDeadLetterQueueRecovery()(on the SQS / ASB transport expressions) that consumes the native DLQ, reconstructs theEnvelopefrom the transport's native dead-letter metadata, and persists viaMoveToDeadLetterStorageAsync.Why
Tools that manage the durable DLQ (e.g. CritterWatch) can only see/replay messages in the durable store — native-DLQ messages are invisible without this bridge. Today only RabbitMQ users get it out of the box. A consistent, built-in feature makes "make my native dead letters manageable" a one-call decision on every transport.
Pairs with
A queryable per-endpoint dead-letter-destination contract (filed separately) so monitors can detect un-bridged native DLQs and recommend enabling this.
Context: JasperFx/CritterWatch#351.