LMS Publishing and Outbox

Summary

Source-backed distinction between outbox staging, registered publication infrastructure, and confirmed delivery.

Audience

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

Reference Content

Invoked helpers validate contracts and convert them to shared outbox records. Records include identity, event type, occurrence, optional correlation/tenant metadata, source, serialized contract, status, retry count, processing time, and error metadata. Payloads are excluded.

The Training outbox store selects Pending or Failed records by occurrence, updates Processed/Failed state, and increments retry count through the shared processor. The outbox event identity is uniquely indexed. Business changes and new outbox records share a local SaveChanges when staged together.

Messaging registration provides the event bus, publisher, and processor; Training registers its outbox store. No Training hosted relay, scheduled processor call, replay, dead-letter handling, cleanup, or reconciliation trigger was found. Therefore:

• Outbox infrastructure registered: yes
• Outbox messages created: yes, for eight contracts
• Relay processor available: yes
• Relay actually triggered by Training: not found
• Transport delivery confirmed: no

Source References

• microservices/src/training-service/Infrastructure/TrainingDbContext.cs
• microservices/src/training-service/Infrastructure/Persistence.cs
• microservices/src/training-service/Program.cs
• microservices/src/shared-kernel/Messaging/OutboxProcessor.cs
• microservices/src/shared-kernel/Outbox/OutboxMessage.cs

Related Articles

• LMS Events documentation
• LMS technical documentation

See Also

• Verified event catalog
• Event limitations

Keywords

• LMS events
• Training contracts
• Source-backed integration

Revision Information

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