Recruitment Event Retry and Failure Handling
Summary
Outbox failures are recorded and retried by later polling; terminal limits, dead-lettering, replay, and Recruitment consumer recovery are not implemented.
Audience
Developers, QA and support engineers, integration reviewers, implementation partners, solution architects, and security reviewers.
Overview
The shared publisher returns failure when broker access or publication fails. The processor stores failed status, error evidence, and an incremented retry count. Pending and failed rows are selected again. No terminal retry count, exponential backoff, poison-message quarantine, dead-letter support, replay command, or manual recovery owner is confirmed for Recruitment.
Workflow, Document, and Employee failures belong to their synchronous command boundaries. Notification consumer retry/dead-letter capability is irrelevant to Recruitment until a Recruitment subscription exists. Persisted outbox intent does not prove delivery, and publication does not prove consumption.
Requires confirmation
Consumer ownership, tenant-envelope policy, correlation/causation policy, retry limits, replay, ordering, contract governance, reconciliation, monitoring, and production support require confirmation.
Source References
microservices/src/shared-kernel/Messaging/OutboxProcessor.csmicroservices/src/recruitment-service/Infrastructure/Persistence.csmicroservices/src/recruitment-service/Messaging/OutboxRelayHostedService.csmicroservices/src/recruitment-service/Application/Commands/RequisitionCommands.csmicroservices/src/recruitment-service/Infrastructure/Gateways.csmicroservices/src/recruitment-service/Infrastructure/EmployeeServiceClient.csmicroservices/src/notification-service/Messaging/NotificationEventConsumer.cs
Related Articles
See Also
Keywords
- Recruitment events
- Retry and Failure Handling
Revision Information
- Status: Draft
- Last reviewed: 2026-07-16
- Review cycle: Quarterly