Attendance Event Retry and Failure Handling

Summary

Failure handling is layered: Attendance retries failed publication through its outbox, consumers may requeue failed deliveries, and Integration Service has bounded dispatch retries plus durable failure/dead-letter handling.

Audience

• Backend developers, DevOps engineers, support engineers, QA engineers, and architects

Failure flow

Attendance’s relay marks publish failures and repolls pending/failed rows. No Attendance-specific terminal attempt cap, dead-letter store, or safe replay endpoint is confirmed. Replay ownership therefore Requires confirmation.

Payroll requeues consumer exceptions. Integration Service uses bounded per-target retry, persists exhausted failures, audits stages, and attempts secondary dead-letter publication. Notification has bounded channel-delivery retry and manual message retry, but these are shared Notification capabilities and do not currently process Attendance events.

Terminal broker-to-Payroll poison-message handling and an Attendance delivery alert threshold are Not implemented / Requires confirmation. Operational replay must be governed; no production replay commands are provided here.

Source References

• microservices/src/shared-kernel/Messaging/OutboxProcessor.cs
• microservices/src/attendance-service/Infrastructure/OutboxRelayHostedService.cs
• microservices/src/integration-service/Orchestration/EventDispatcher.cs
• microservices/src/integration-service/Messaging/IntegrationEventConsumer.cs
• microservices/src/payroll-service/Messaging/PayrollReadModelConsumer.cs
• microservices/src/notification-service/Application/NotificationDispatcher.cs

Related Articles

• Attendance events
• Attendance technical documentation
• Attendance database documentation

See Also

• Attendance API documentation
• Attendance business documentation

Keywords

• Attendance events
• Integration contracts
• Eventual consistency

Revision Information

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