Regression Analysis: Race condition risk in compensatePaymentIfNeededStep (PR #15527)

[kapil971390]

Hey team

I ran a regression analysis on PR #15527 — "fix(core-flows): avoid refunding captures made in separate completeCartWorkflow executions" — and wanted to share the findings with the community in case it helps with QA before the next release.

Risk Assessment: HIGH

The compensation step now performs database queries to check order status before refunding. If these queries return stale data or the order-cart link is not yet committed when compensation runs, payments could still be double-refunded or fail to refund when they should.

Escalated from MEDIUM — payment refunds are irreversible operations that directly affect customer funds.

What to Test

1. Race condition (core scenario): Trigger two concurrent completeCartWorkflow executions with the same payment_session_id. Force the first to fail after payment capture. Verify the second places the order successfully AND the first's compensation does NOT refund the captured payment.

2. Legitimate failure path: Trigger compensatePaymentIfNeededStep for a payment_session_id where no order was placed (genuine cart failure). Verify refund still triggers correctly.

3. Stale DB read: Simulate the order-cart link query returning empty/null due to replication lag. Verify the compensation does not incorrectly skip the refund.

4. Concurrent compensation: Call compensatePaymentIfNeededStep twice in rapid succession with the same payment_session_id. Verify no double-refund is created.

5. Null payment_session_id: Pass null or undefined to the step. Verify it fails gracefully without corrupting state.

Where It Can Break

• Stale cache read: Order placed successfully, but order-cart link not yet written to DB when compensation runs → compensation refunds a valid payment, leaving order with no payment.
• Missing cart link: cart_payment_collection link is absent → order-cart query returns empty → compensation can't detect the order → incorrect refund.
• Concurrent compensations: Two compensation steps race against each other → both see no order at the same time → double refund.
• Silent exception: Error in refundPaymentAndRecreatePaymentSessionWorkflow is swallowed → no log, no refund, captured payment stranded.

Edge Cases

• Stale compensation refunds a valid payment before the order-cart link is detected → placed order loses its payment + customer gets an unexpected refund.
• Query failure is silently caught → compensation returns early → payment remains captured with no refund and no audit trail.
• Two compensations run simultaneously → duplicate refund records or orphaned payment sessions.

Final Verdict

Before shipping, I'd recommend explicitly testing the race condition scenario: two concurrent completeCartWorkflow runs on the same payment session — one fails after capture, one succeeds and places the order. The compensation from the failed run must not refund the payment tied to the successful order.

Also verify that legitimate failures (inventory check fails, shipping fails) with no prior order still trigger refunds as expected.

Happy to share the full detailed report if useful