Notification Publishers
Summary
Notification registers the shared publisher stack but calls it from exactly one place: the test-publish endpoint. No business publish path exists.
Audience
Engineers, architects, QA, support and DevOps engineers.
Reference Content
The verified reference material for this topic is set out in the sections below.
Registered publisher components
The shared messaging registration adds three things, all with try-add semantics so a service can substitute its own:
| Component | Lifetime | Used by Notification |
|---|---|---|
| Event bus over the broker | Singleton | Yes — test hook only |
| Integration-event publisher | Singleton | No |
| Outbox processor | Scoped | Resolves to the no-operation implementation |
The outbox processor selection is conditional: when a message store is registered the real processor is created, otherwise the no-operation one is. Notification registers no message store, so it gets the no-operation processor and no outbox relay runs.
Publish contract
The event bus exposes two overloads: one taking a typed integration event, and one taking an event type, a payload string and a metadata dictionary. Notification uses the untyped overload, because the test hook publishes a caller-supplied type.
The typed overload builds its metadata from the contract's own fields; the untyped overload takes the caller's dictionary verbatim.
Publish behavior
| Aspect | Verified behavior |
|---|---|
| Exchange | The shared integration-events exchange |
| Routing key | The event type |
| Delivery mode | Persistent |
| Content type | JSON |
| Message id | The event identifier from metadata, else a new GUID |
| Correlation id | From metadata when present, else null |
| Timestamp | Current instant in seconds |
| Headers | Every metadata entry with a non-blank value |
| Mandatory flag | False |
| Return value | Boolean — true on success |
Failure semantics
Two failure modes are handled and both are non-throwing:
- When no channel can be obtained, the publish returns false without attempting to send.
- When the send itself throws, the exception is caught, logged as a warning stating the message remains eligible for retry, and false is returned.
The publisher therefore never surfaces a broker failure as an exception. Whether anything acts on the false return is the caller's concern — for Notification's test hook, false produces a bare gateway-error status.
No delivery confirmation. The mandatory flag is false and publisher confirms are not enabled, so a message routed to no queue is silently discarded by the broker and the publish still reports success.
Connection handling
The channel is created lazily and reused while open, guarded by a semaphore so concurrent publishes do not race to create duplicates. The connection and channel are disposed on disposal of the bus.
Classification
Foundation — the publisher stack is available and correct; Notification uses it only for verification.
Requires confirmation
Whether publisher confirms or mandatory routing are intended for the platform requires confirmation.
Related Articles
See Also
Keywords
- Notification database
- Publishers
- Draft database documentation
Source References
microservices/src/shared-kernel/Messaging/RabbitMqEventBus.csmicroservices/src/shared-kernel/Messaging/IEventBus.csmicroservices/src/shared-kernel/Extensions/MessagingExtensions.csmicroservices/src/notification-service/Api/NotificationEndpoints.csmicroservices/src/notification-service/Program.cs
Revision Information
- Status: Draft
- Last reviewed: 2026-07-21
- Review cycle: Quarterly