From the eShop (AdventureWorks), mapped as three services architecture map
Awaiting-validation stock check confirms orders for unknown product ids
The awaiting-validation handler looks up each ordered product with CatalogItems.Find and skips any id that comes back null; it rejects only when a found item lacks stock. So an order made entirely of unknown product ids gets OrderStockConfirmedIntegrationEvent. Nothing is reserved either: the paid handler later calls CatalogItem.RemoveStock, which throws CatalogDomainException once stock is zero.
Impact: An order for a nonexistent or already-removed product clears validation as confirmed, and the failure only surfaces later as an unhandled exception when the paid handler tries to remove stock, instead of as a rejection at the point the catalog actually knows the product id is unrecognised.
Recommendation (small effort): In the awaiting-validation handler, treat a null CatalogItems.Find result as a rejected line instead of skipping it, so an order of unrecognised products is rejected before payment.
The trail
- Ordering Service
- Event Bus
- Catalog API
- Catalog API Host & Bootstrap
- Catalog Persistence Layer
- Catalog AI (Embedding) Service
- Text Embedding Provider
More 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
- 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