Expense Event Retry and Failure Handling

Summary

Expense retries failed publication through repeated hosted-relay scans. Payroll and Notification requeue deliveries when consumer processing throws. Retry limits and dead-letter handling are not implemented in the confirmed Expense flow.

Confirmed failure paths

The relay processes Pending and Failed rows, so a poison publication can remain repeatedly eligible. Its regular polling delay provides spacing between scans, but there is no event-specific or exponential backoff. Relay-loop exceptions are logged and do not terminate the hosted service.

Notification channel delivery has its own downstream retry policy. That is not Expense publication retry and does not alter the Expense outbox row.

Not implemented

• Expense retry ceiling
• Expense dead-letter queue or store
• Poison-message quarantine
• Administrative replay API
• Per-event backoff schedule
• Confirmed alert or monitoring escalation

Requires confirmation

Retry ownership, maximum attempts, dead-letter operations, replay authorization, poison-message handling, and monitoring thresholds require confirmation.

Source References

• microservices/src/expense-service/Infrastructure/Persistence.cs
• microservices/src/shared-kernel/Messaging/OutboxProcessor.cs
• microservices/src/expense-service/Messaging/OutboxRelayHostedService.cs
• microservices/src/payroll-service/Messaging/PayrollReadModelConsumer.cs
• microservices/src/notification-service/Messaging/NotificationEventConsumer.cs
• microservices/src/notification-service/Application/NotificationDispatcher.cs

Related Articles

• Expense events documentation
• Expense technical documentation
• Expense database documentation

See Also

• Expense API documentation
• Expense module

Keywords

• Expense events
• Retry and Failure Handling
• Integration contracts

Revision Information

• Status: Draft
• Last reviewed: 2026-07-16
• Review cycle: Quarterly