Summary
Expose, as a uniform queryable contract, whether a given endpoint's dead letters go to a native broker DLQ vs the durable message store (and whether native→durable recovery is enabled) — so monitoring tools can introspect it without transport-specific knowledge.
Today
Where an endpoint's failures end up is encoded in transport-specific config:
- SQS:
DeadLetterQueueName / DisableDeadLetterQueues / DisableDeadLetterQueueing()
- RabbitMQ:
DeadLetterQueueMode (Native / InteropFriendly / WolverineStorage) + EnableDeadLetterQueueRecovery()
- Azure Service Bus: native
$DeadLetterQueue sub-queue
There's no transport-agnostic, queryable property that says "this endpoint's dead letters go to durable storage" vs "native, un-bridged."
Ask
A first-class property on the endpoint/transport model — e.g. an enum like DeadLetterStorage { Native, Durable, NativeWithRecovery } (or a bool) — exposed via IWolverineRuntime / endpoint introspection, declaring each endpoint's effective dead-letter destination.
Why
A monitor like CritterWatch manages only the durable DLQ. It wants to detect, at startup, endpoints that dead-letter natively without recovery to durable and recommend the fix. Inferring this per-transport leaks transport-specific knowledge into the monitor and is fragile across versions; a declared, queryable contract makes it a clean read.
Pairs with
The first-class native-DLQ recovery feature (filed separately) — together they let a monitor (a) detect un-bridged native DLQs and (b) point users at the one-call fix.
Context: JasperFx/CritterWatch#351.
Summary
Expose, as a uniform queryable contract, whether a given endpoint's dead letters go to a native broker DLQ vs the durable message store (and whether native→durable recovery is enabled) — so monitoring tools can introspect it without transport-specific knowledge.
Today
Where an endpoint's failures end up is encoded in transport-specific config:
DeadLetterQueueName/DisableDeadLetterQueues/DisableDeadLetterQueueing()DeadLetterQueueMode(Native/InteropFriendly/WolverineStorage) +EnableDeadLetterQueueRecovery()$DeadLetterQueuesub-queueThere's no transport-agnostic, queryable property that says "this endpoint's dead letters go to durable storage" vs "native, un-bridged."
Ask
A first-class property on the endpoint/transport model — e.g. an enum like
DeadLetterStorage { Native, Durable, NativeWithRecovery }(or abool) — exposed viaIWolverineRuntime/ endpoint introspection, declaring each endpoint's effective dead-letter destination.Why
A monitor like CritterWatch manages only the durable DLQ. It wants to detect, at startup, endpoints that dead-letter natively without recovery to durable and recommend the fix. Inferring this per-transport leaks transport-specific knowledge into the monitor and is fragile across versions; a declared, queryable contract makes it a clean read.
Pairs with
The first-class native-DLQ recovery feature (filed separately) — together they let a monitor (a) detect un-bridged native DLQs and (b) point users at the one-call fix.
Context: JasperFx/CritterWatch#351.