The DefaultStockLocationStrategy was the default implementation of the StockLocationStrategy prior to the introduction of the MultiChannelStockLocationStrategy. It assumes only a single StockLocation and that all stock is allocated from that location. When more than one StockLocation or Channel is used, it will not behave as expected.
Since 3.7.4, forAllocation() caps each allocation at the stock the ProductVariant actually has
available, read under a write lock. With the default DefaultStockAllocationStrategy the
saleable stock check runs on the transition to ArrangingPayment and the allocation runs on the
transition to PaymentSettled, in a later request, so another Order can take the stock in
between. Before 3.7.4 the allocation went through at the full quantity and oversold the variant.
Now the Order which loses that race is allocated less than it ordered, and
StockShortfallEvent reports the shortfall. The customer has already paid at that point,
and core neither refunds nor cancels the Order: subscribe to the event to decide what to do.
(ctx: RequestContext, productVariantId: ID, stockLevels: StockLevel[]) => AvailableStock(ctx: RequestContext, stockLocations: StockLocation[], orderLine: OrderLine, quantity: number) => Promise<LocationWithQuantity[]>v3.7.4 - The quantity is capped and the StockLevels are read under a lockAllocates from the first StockLocation, capped at the quantity the ProductVariant still has
available: stockOnHand - stockAllocated - outOfStockThreshold, summed over every
StockLevel of the variant, which is the same figure the saleable stock check uses. The
StockLevels are read under a write lock, so a concurrent allocation of the same variant
waits and then sees this one's result.