mollie / magento2-hyva-checkout

8 stars 7 forks source link

524 Timeout - /checkout/onepage/success #28

Closed pjw345 closed 1 month ago

pjw345 commented 2 months ago

We are using:

After a customer has processed the payment in Mollie, they are redirected back to the success page on our site and some are experiencing very long wait times and sometimes even 524 errors that we see logged in Cloudflare.

Now we have reached out to Mollie, Cloudflare and Hypernode in a attempt to find a solution to this issue. We didn't see this happening when we were using Stripe (which we had to stop using as there is an issue with redirecting to Paypal and 3D)

On Cloudflare we have Mollie's IP addresses whitelisted, on the server there are no ratelimiting restrictions on Mollie and we've checked out CSP policies. There is nothing glaringly obvious and we were wondering if anybody had experienced this and found a solution

fjbender commented 2 months ago

We have seen some weird things with Cloudflare, but usually allowlisting our IPs solved things. I recommend you reach out in our Developer Discord so we can take a closer look at some examples.

pjw345 commented 2 months ago

With the help of New Relic we were able to trace it down to the fact that during the checkout process it would appear they are running a query on the sales_order table selecting all records for a specific customer_email.

Our sales_order table has over 2 million records and the customer_email field is NOT indexed. The simple fix was to add an index to the sales_order table for the customer_email field and the query now runs in the milliseconds, but one still has to ask why are they querying the sales_order table?

Like I mentioned, this was not something we experienced with the Stripe module

fjbender commented 2 months ago

Many thanks for putting in the time and effort to do this research! Can you share the exact point where we trigger that query? I am wondering whether it's in this plugin or in mollie/magento2

pjw345 commented 2 months ago

I suspect it is in the mollie/magento2 and not in this plugin, hence the issue can be closed here

Frank-Magmodules commented 2 months ago

Hi there @pjw345 ,

We haven’t seen an issue about this opened in the mollie/magento2 repository yet. We still did some investigations, but couldn’t find a point where the Mollie extensions are selecting records based on the customer_email. If you really think this is an issue with the Mollie extension, would you then be so kind to share a little bit more information about your find so that we can take action on that? Thanks!

pjw345 commented 2 months ago

Have a look at \Mollie\Payment\Service\Order\DeletePaymentReminder where they select orders based on customer_email. As I said previously customer_email is NOT indexed on sales_order and if you have a shop like ours where we have over 2 million records in the table this will cause a problem.

Frank-Magmodules commented 2 months ago

Hi @pjw345, I'm reopening this issue as we are still investigating your comments. We understand the issue you're pointing out, but we don’t have a clear solution just yet. However, one will follow soon, and I'll share the update with you!

pjw345 commented 2 months ago

My solution was to alter the table and add an index to the sales_order table. However I am sure this can also be done in Magento by creating the appropriate db_schema.xml in the Mollie module.

<table name="sales_order" resource="sales" comment="Sales Flat Order">
    <index referenceId="SALES_ORDER_CUSTOMER_EMAIL" indexType="btree">
        <column name="customer_email"/>
    </index>
</table>
Frank-Magmodules commented 1 month ago

Hi @pjw345, good news! We've added this as an improvement in the upcoming release, where we no longer depend on the sales_order table in this case. I'll keep this ticket open for now, and although the fix will be included in the main module, I'll follow up and close the ticket once it's released. Thanks for your patience!

Frank-Magmodules commented 1 month ago

We’ve released this, so I’m closing the issue. Thanks again!