Payroll Event Retry and Failure Handling
Summary
This page documents confirmed payroll event retry and failure handling behavior and explicitly marks incomplete integration boundaries.
Audience
Payroll and integration developers, QA and support engineers, solution and security architects, and implementation partners.
Outbound failures
The shared outbox processor marks a record Failed and increments its retry count when publication fails. Pending and Failed records remain eligible for later batches. No Payroll-specific retry ceiling, schedule, or dead-letter transition is confirmed.
Inbound failures
The Payroll projection consumer retries broker connection after failures. A delivery exception causes negative acknowledgement with requeue. Successful ApplyAsync completion is followed by acknowledgement.
Dead-letter and replay
No Payroll-specific dead-letter queue, poison-message cutoff, quarantine record, or operator replay command is confirmed. Integration Service has separate dead-letter capability but does not subscribe to Payroll events, so it is not documented as a Payroll-event safeguard.
Failure windows
Publication success and outbox status update are separate operations, allowing duplicate publication after an intervening failure. Consumer ledgers mitigate duplicates where implemented.
Requires confirmation
- Relay scheduling, bounded retry, backoff, poison-message handling, alerting, and replay ownership.
- Recovery from publish-success/status-save failure.
Source References
microservices/src/payroll-service/Messaging/PayrollReadModelConsumer.csmicroservices/src/shared-kernel/Messaging/OutboxProcessor.csmicroservices/src/payroll-service/Infrastructure/Persistence.csmicroservices/src/integration-service/Domain/IntegrationEntities.cs
Related Articles
See Also
Keywords
- Payroll events
- Payroll Event Retry and Failure Handling
- Integration contracts
Revision Information
- Status: Draft
- Last reviewed: 2026-07-15
- Review cycle: Quarterly