From the eShop (AdventureWorks), mapped as three services architecture map
Identified Command swallows a failed CreateOrder and still reports success on retry
Identified Command records the request id before running the wrapped command, then catches any inner failure and returns false. The OrderStarted event that clears the basket is already saved in the same transaction, which still commits. A retry with the same id counts as a duplicate, so Create Order returns true and no order exists. This wrapper sits in front of 8 command handlers.
Impact: A buyer's basket can be cleared with no order created, and a retry hides the failure by reporting success, while every other order command inherits the same silent-catch idempotency behavior.
Recommendation (medium effort): In Identified Command's catch block, log the swallowed exception and return a result that distinguishes failure from a genuine duplicate, so a failed inner command cannot masquerade as a successful retry.
The trail
- Identified Command
- Cancel Order Command
- Create Order Command
- Create Order Draft Command
- Set Awaiting Validation Order Status Command
- Set Paid Order Status Command
More from this board
- 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
- RabbitMQ status handlers skip the idempotency check HTTP commands get
- 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