Memory exhausted - possibly a bug in checkout

[martbase]

I am encountering memory allocation issues (Allowed memory size exhausted) at the last step of the Checkout process when I click Complete Order

The Web Console reports an Internal Server error on the following request:-

POSThttps://www.yangyumchicken.com/yangyum/checkout/submit [HTTP/2 500 Internal Server Error 2780ms]

and a Whoops\Exception\ErrorException (E_ERROR) page is then displayed

On clicking Complete Order, it doesn't even get to the getAction() method!!! (I have console log statements in the methods)

I have attached the Concrete5 Environment settings together with a link to Xdebug Cachegrind profiler output just in case someone can figure out why this is happening

Concrete5 Environment

https://www.martbits.net/hpanel/bugreport/callgrind.out.3781457._yangyum_checkout.zip

Environment & details: Server LiteSpeed Concrete5 8.5.4 Custom Theme based on Bootstrap 4 Community Store 2.3.1 Community Store Payment Addon based on Community Store Stripe Checkout and Community Store Paypal Standard - redirects to an external payment provider (checkoutForm()->getAction()->redirectForm()->validateCompletion())

            // exclude verbose information (e.g. exception stack traces)
            if (class_exists('Symfony\Component\VarDumper\Caster\Caster')) {
                $cloneVar = $this->getCloner()->cloneVar($value, Caster::EXCLUDE_VERBOSE);
                // Symfony VarDumper 2.6 Caster class dont exist.
            } else {
                $cloneVar = $this->getCloner()->cloneVar($value);
            }

            $dumper->dump(
                $cloneVar,
                $this->htmlDumperOutput
            );

            $output = $this->htmlDumperOutput->getOutput();
            $this->htmlDumperOutput->clear();

            return $output;
        }

        return htmlspecialchars(print_r($value, true));
    }``` 

[Mesuva]

I've seen this kind of error occur due to some other error triggering debugging where PHP simply can't handle outputting some object or class, due to recursion or similar.

Try winding the debugging back to just showing the error message rather than the full whoops display, to see if you end up with a more meaningful error.

[martbase]

Hi Ryan,

Do you mean changing Concrete5's Debug settings Error Detail to Show the error message but nothing else?

I had spent a significant amount of time trying to troubleshoot the issue but wasn't getting anywhere. Even increasing PHP memory limit from initial 256MB to 515MB and 1GB didn't work - allocated memory was still exhausted.

I have since switched to a different hosting plan so don't have access to the host that had the issue. I picked a regular cPanel plan where I don't encounter the issue although for some reason after redirecting to the payment processor and completing payment it doesn't redirect to the checkout/complete page! It get's stuck at the payment processor callback/return address with a blank page:- https://www.martbits.net/c5shop/checkout/ipayredirectresponse?status=aei7p7yrx4ae34&txncd=346521830902&msisdn_id=JOHN+DOE&msisdn_idnum=0721341039&p1=test&p2=38&p3=500.00&p4=0721341039&uyt=688365301&agt=820504798&qwh=141798848&ifd=450662635&afd=840743267&poi=268629857&id=38&ivm=38&mc=500.00&channel=MPESA

Adding header('Location: '.URL::to('/checkout/complete')); in validateCompletion() doesn't seem to work

[Mesuva]

Yes, that's the setting I mean. I've encountered times where it just runs out of memory trying to show the full whoops message, but when I've set the debug to just show the error message it's ended up being some trivial error to resolve.

For your new issue, I don't have an immediate answer to that one. What payment method are you using in this case?

[martbase]

Thanks, when I get some spare time I'll try and replicate the original setup and have a look at it again.

The payment method is based on the PayPal Standard one with modifications to handle the particular Payment Gateway.

[martbase]

Yes, that's the setting I mean. I've encountered times where it just runs out of memory trying to show the full whoops message, but when I've set the debug to just show the error message it's ended up being some trivial error to resolve.

For your new issue, I don't have an immediate answer to that one. What payment method are you using in this case?

I am glad to report that I resolved the issue with redirecting to the checkout/complete page. I developed the site on a local Windows machine then migrated it to a Linux host and that may be the root of problems I encountered. Turned out table names had the correct case since I had the lower_case_table_names=2 MySQL setting but constraint names were all in lowercase!!! Edited the database dump and after re-importing and testing the redirection works as expected.

By the way should header('Location: '.URL::to('/checkout/complete')); be included in validateCompletion() to have the page redirect from an external payment processor or should that be handled automatically by CS?

[Mesuva]

Great to hear you've got it resolved. That table casing issue has caught many people out!

It really all comes down to how you've developed the payment method. In other methods, the 'validateCompletion' function is normally one that is called from the payment gateway directly to the server, so that can't trigger a redirect, as it's not the customer actually making the request. In the paypal one for example, it's used to handle the callback from Paypal that actually marks an order as paid.

Every payment gateway works a bit differently, so putting a bit more logic/configuration in each one instead of directly in the checkout flow is often a good tradeoff with having more flexibility.

If you'd like me to take a look at your custom gateway code feel free to reach out.

[martbase]

Ok got it, thanks for the detailed explanation and for the awesome eCommerce solution. I'll close this issue for now but may reopen it in case I get some spare time and ran tests on the original environment and encounter similar errors.