Ensuring Flawless Orders: Addressing a Race Condition in ESHOPMAN's Cart Completion Workflow

Ensuring Flawless Orders: Addressing a Race Condition in ESHOPMAN's Cart Completion Workflow

At Move My Store, we prioritize reliable order processing for ESHOPMAN merchants leveraging HubSpot for storefront management. Ensuring accurate transactions and perfect inventory management is critical. This community insight details a high-impact race condition recently identified and resolved within ESHOPMAN's core workflow orchestration engine, which could lead to "orphaned orders."

The Challenge: Concurrent Cart Completions and Orphaned Orders

In high-traffic scenarios, like sales events, multiple customers might simultaneously purchase the last units of a popular item. A subtle but significant race condition was observed in ESHOPMAN platform version 2.19.0. When distinct carts competed for shared, limited inventory, the system could, under specific timing, create more orders than available stock. This left some orders "orphaned"—an order row existed, but lacked a corresponding inventory reservation and payment capture.

This issue is distinct from previous fixes for scenarios where the same cart was submitted multiple times. This bug specifically concerns different carts racing for the same inventory item, a situation not covered by earlier per-cart locking mechanisms.

Unpacking the Technical Root Cause

The problem originates within ESHOPMAN's sophisticated workflow orchestration engine, specifically during the completeCartWorkflow. This workflow utilizes parallel steps for performance, including the slower reserveInventoryStep (involving database work) and faster steps like emitEventStep, updateCartsStep, and createRemoteLinkStep.

The issue unfolded as follows:

1. When concurrent cart completions occurred, faster steps in the parallelize() batch within completeCartWorkflow would successfully complete and reach an OK status before the slower reserveInventoryStep for a losing cart failed due to insufficient inventory.
2. Upon reserveInventoryStep's failure, ESHOPMAN's transaction orchestrator (TransactionOrchestrator.setStepFailure) attempted to mark all steps in that parallel batch as failed (TEMPORARY_FAILURE) to trigger compensation.
3. However, TransactionStep.changeStatus has strict allowed transitions and does not permit changing a step from OK to TEMPORARY_FAILURE.
4. Attempting this transition on an already-OK sibling step threw an uncaught exception, prematurely aborting the entire failure-handling pass.
5. Consequently, the crucial compensation logic for createOrdersStep (designed to deleteOrders upon failure) never executed.

The result: an order row persisted without inventory reservation or payment, an "orphaned" order misrepresenting actual sales and inventory.

The ESHOPMAN Community Solution

A targeted and verified fix, identified by the ESHOPMAN community, involves a critical adjustment to the guard condition within the transaction orchestrator's failure handling. By adding an explicit check to ensure a step's status is not already OK before attempting to mark it as TEMPORARY_FAILURE, we prevent the erroneous status transition and subsequent exception.

Here's the essential code modification:

 if (!isTimeout &&
     step.getStates().status !== types_1.TransactionStepStatus.PERMANENT_FAILURE &&
+    step.getStates().status !== types_1.TransactionStepStatus.OK) {
     step.changeStatus(types_1.TransactionStepStatus.TEMPORARY_FAILURE);
 }

This change ensures the orchestrator gracefully skips redundant status changes for already-completed steps, allowing the failure-handling pass to continue uninterrupted. This guarantees all necessary compensation actions, like deleting orphaned order rows, execute correctly.

Verified Impact and Enhanced Reliability

This fix was rigorously tested, including stress tests with 50 concurrent requests against a 2-unit inventory pool. Results showed exactly two legitimate orders, each with a real reservation and captured payment, and zero orphaned orders. ESHOPMAN's existing comprehensive test suite remained green, confirming no regressions.

This insight highlights ESHOPMAN's commitment to robust e-commerce operations. Addressing intricate race conditions like this ensures ESHOPMAN merchants can confidently manage their storefronts via HubSpot, knowing their order data and inventory are accurate, even under peak load. This community-driven problem-solving continuously enhances the platform's stability and performance.