From the eShop (AdventureWorks), mapped as three services architecture map
A rejected order still empties the shopper's bag
BasketState.CheckoutAsync awaits OrderingService.CreateOrder and then unconditionally deletes the basket. CreateOrder returns the raw HttpClient.SendAsync result and never checks the status code, so a 400 or 500 from the Ordering API looks like success. Checkout.razor then navigates straight to the orders page with no failure branch. All 3 of Basket State's dependents go through it, so every checkout takes this path.
Impact: A shopper who submits an order the Ordering API rejects sees their cart emptied and lands on an order history page where the order they just placed does not appear, with no error and no way to recover the cart contents.
Recommendation (small effort): Have OrderingService.CreateOrder check the response status and throw or return a result on failure, and have BasketState.CheckoutAsync only clear the basket after a confirmed success; Checkout.razor should show an error and keep the cart when checkout fails.
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
- 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 retired catalog item breaks Cart Menu's basket load everywhere