Skip to main content

LMS Retry and Failure Behavior

Summary

Retry metadata and failure transitions exist, but Training has no verified relay trigger or terminal publication limit.

Audience

Engineering, integration, QA, architecture, security, product, and support reviewers.

Reference Content

The Training outbox store returns pending or failed records for processing. When the shared processor is invoked, it publishes sequentially, marks success as processed, and records failed attempts for a false result or exception. The record retains retry and error metadata. No maximum publisher retry, active replay, cleanup, or reconciliation flow was found, and Training has no verified hosted relay trigger.

Notification requeues unexpected consumer-infrastructure failures. Its dispatcher applies bounded delivery attempts and records terminal delivery failure. A failed individual delivery does not necessarily prevent the integration event from being recorded as processed. No active dead-letter wiring was found in the consumer declaration. Numeric configuration and infrastructure details are intentionally excluded.

Publication, reconciliation, retention, and terminal-failure ownership Require confirmation.

Source References

  • microservices/src/training-service/Infrastructure/Persistence.cs
  • microservices/src/shared-kernel/Messaging/OutboxProcessor.cs
  • microservices/src/notification-service/Messaging/NotificationEventConsumer.cs
  • microservices/src/notification-service/Application/NotificationDispatcher.cs

See Also

Keywords

  • Outbox retry
  • Consumer failure
  • Reconciliation ownership

Revision Information

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