From the eShop (AdventureWorks), mapped as three services architecture map
RabbitMQ status handlers skip the idempotency check HTTP commands get
Every RabbitMQ event handler in Ordering API sends its status command straight to MediatR and skips the IdentifiedCommand wrapper that HTTP requests get. SetPaidIdentifiedOrderStatusCommandHandler exists to ignore duplicates, but nothing sends it. The same is true for SetStockConfirmed, SetStockRejected and SetAwaitingValidation. A redelivered payment, stock or grace-period message runs a status change that was already applied.
Impact: A redelivered event from the payment, catalog or grace-period worker silently repeats an order status transition, with no idempotency check to stop it.
Recommendation (medium effort): Route each integration-event handler's status command through its existing Identified*OrderStatusCommandHandler (keyed by the event id) instead of calling mediator.Send on the bare command, the way OrdersApi already does for HTTP.
The trail
Open on the mapMore from this board
- Identified Command swallows a failed CreateOrder and still reports success on retry
- An unreachable embedding model blocks product price changes
- Failed catalog price-change events are marked failed and never retried
- Order Queries reads straight from the write side's OrderingContext, not a separate read model
- Awaiting-validation stock check confirms orders for unknown product ids
- Order-status updates only reach shoppers on the WebApp process that handled the event
- A rejected order still empties the shopper's bag
- A retired catalog item breaks Cart Menu's basket load everywhere