[Race condition] PrestaShop Checkout v9.5.1.0 duplicate status "Payment received"

[Chrsch76]

I have a problem with the PrestaShop Checkout Module v9.5.1.0 under PrestaShop 9.02. When paying with PayPal, the status "Payment received" is set or triggered twice. As a result, the customer receives the confirmation from our shop twice and also receives the PayPal email twice. However, the payment was definitely made only once. Another problem is that the PDF invoice is not generated automatically.

[floods57]

I have the exact same problem since update to 5.1.0 (7.5.1.0 on PS 1.7.7.8), it happen when customer pay by Paypal, but not all the time.

[louisbels]

Hi,

We investigated this issue in depth and found the root cause: a race condition between concurrent requests.

When a customer pays with PayPal, 3 requests arrive simultaneously:

1. POST /module/ps_checkout/validate (front-end, triggered by the customer)
2. POST /?fc=module&module=ps_checkout&controller=DispatchWebHook (PayPal webhook 1)
3. POST /?fc=module&module=ps_checkout&controller=DispatchWebHook (PayPal webhook 2)

Confirmed via nginx access logs:

11:11:13 POST /module/ps_checkout/validate                                    <- customer browser
11:11:13 POST /?fc=module&module=ps_checkout&controller=DispatchWebHook       <- PayPal webhook 1
11:11:14 POST /?fc=module&module=ps_checkout&controller=DispatchWebHook       <- PayPal webhook 2

Another example:

12:06:15 POST /?fc=module&module=ps_checkout&controller=DispatchWebHook       <- PayPal webhook 1
12:06:15 POST /module/ps_checkout/validate                                    <- customer browser
12:06:19 POST /?fc=module&module=ps_checkout&controller=DispatchWebHook       <- PayPal webhook 2

The validate controller calls CapturePayPalOrderAction, which triggers the PayPal webhooks. They arrive while validate is still processing.

All three paths converge on OrderHistory::changeIdOrderState() → Order::setInvoice(). The hasInvoice() guard has no lock, so multiple processes can pass it simultaneously, causing:

• Duplicate invoices (one empty with 0 products, one real)
• Duplicate payments (one "PayPal" with transaction_id, one "PrestaShop Checkout" without)
• Duplicate order status history entries

Workaround: Add sleep(3) in controllers/front/DispatchWebHook.php before processing. This lets the validate request finish first, after which all existing guards work correctly.

// controllers/front/DispatchWebHook.php - display() method
$logger->info("Webhook dispatch initiated");

// Workaround: sleep to avoid race condition with /module/ps_checkout/validate
sleep(3);

Proper fix: A file lock (flock) on the PayPal Order ID should be added in both DispatchWebHook.php and validate.php controllers to serialize processing and prevent the race condition entirely.

Note: PR 1471 addresses the idempotency of the PayPal capture API call (ORDER_ALREADY_CAPTURED), but does not fix the race condition on PrestaShop side (setInvoice(), duplicate payments, duplicate status history).

Same root cause as discussion 1451 and discussion 1430.

cc @matks

[matks]

Hello @louisbels thank you the very accurate report, I commit to answer next week, but I wanted to deep dive in your nice insights firsts 👍

[matks]

Hello @louisbels as you said PR 1471 will not eliminate the existence of race conditions, it will mitigate them. The only way to prevent race condition sis to have a lock mechanism such as the one you described to make sure we only process once a given action.

However the flock solution does not look the right shot for us. Over years, we've been observing how people use our modules and we know we have thousand of people installing it in very different setups, conditions, environment, configurations. Some PrestaShop stores are lightning fast, some are struggling with CPU. Some have top notch capabilities, some... are slow as snails 😅 . Some have a few modules installed, some have up to 100 modules installed, sometimes hooked on the same hook, so they are triggered in sequence and the order validation can become very long (and sometimes timeout).

If we implement the flock solution, we are quite sure that statistically speaking we will observe cases where the file lock stays in place. I am 100% sure of that. On some stores, due to timeouts, due to long running processes, due to the environment configurations (file I/O permissions will also apply), it will happen that the file lock will stay in place. It's a sad story but I'm sure this will happen.

Basically... PrestaShop environments are not reliable because we don't control them 😅 . It's one of the main constraints of building a module that you then distribute to the world: we have no mean to know what the target install environment will look like. But we have years of experiences and customer feedback that tell us a file lock is a solution that will create issues in some environments.

So in the last weeks we have been identifying other mitigations and strengthening them, one by one. See for example Pull Requests milestoned 5.1.1.

Also we have added more logs in the 5.1.1 module to have better visibility of what is exactly happening as on localhost we cannot reproduce exactly what is happening (race conditions are a nightmare to simulation).

For PR 1471 we think that a fair number of problems would trigger because when we fetch the order data from the database, we actually do not get a fresh version of the data because of PrestaShop core built-in cache mechanism.

We are going to continue working on

• mitigations to counter unwanted consequences of race conditions
• looking for a reliable solution to eliminate race conditions

[matks]

Hello I have good news 😄

We have published a new version v5.2.0 which should strongly mitigate the race condition issue thanks to a fix on API side. There are still things to improve on module side but the mitigation should be very efficient I believe.

@louisbels we are considering the idea of relying on multiple locks solutions because we know on some hosting environments the flock won't work, on some other environments a database entre won't be efficient... so instead of trying to find "the fix that works in every environment" we might have multiple solutions and allow merchants/developers to pick.