Notification Dead-Letter Processing
Summary
Dead-letter processing is configured but not wired. Two settings name a dead-letter exchange and queue; nothing in the reviewed source references them.
Audience
DevOps engineers, engineers, architects, QA and support.
Dead-letter flow
What is configured
The Notification options type declares two string settings under its broker topology group, defaulting to a platform dead-letter exchange name and a service-specific dead-letter queue name.
Both are bound from configuration like every other option. Both are unreferenced: no consumer code, no declaration call and no publish path reads either value.
What is declared
The queue is declared durable, non-exclusive and not auto-deleted, with arguments explicitly null. The dead-letter exchange argument is the mechanism by which a queue routes rejected, expired or overflowing messages to a dead-letter destination. Passing no arguments means no such routing is configured.
No dead-letter exchange is declared, no dead-letter queue is declared, and no binding between them is created.
Configured versus operational
This distinction matters for anyone reading the configuration and assuming a safety net exists.
| Aspect | State |
|---|---|
| Dead-letter names present in configuration | Configured |
| Queue declared with dead-letter arguments | Not wired |
| Dead-letter exchange declared by the service | Not declared |
| Dead-letter queue declared by the service | Not declared |
| Code that consumes or inspects dead-lettered messages | None |
Whether an operator has applied a broker-side policy that supplies dead-lettering out of band is outside the repository and is classified Requires confirmation. This documentation asserts nothing about the deployed broker.
Consequence
Because the consumer always requeues rather than rejecting, and the queue has no dead-letter destination, there is no path by which a message leaves the queue other than successful processing. A permanently failing message cannot be parked, inspected or drained through any mechanism the code provides.
Classification
Not implemented.
Requires confirmation
Whether the dead-letter names are intended to be wired, and whether a broker-side policy currently supplies dead-lettering, require confirmation.
Related Articles
See Also
Keywords
- Notification database
- Dead-Letter Processing
- Draft database documentation
Source References
microservices/src/notification-service/Application/NotificationOptions.csmicroservices/src/notification-service/Messaging/NotificationEventConsumer.cs
Revision Information
- Status: Draft
- Last reviewed: 2026-07-21
- Review cycle: Quarterly