Improve Checkout error handling in JS

[luisramos0]

• Switch from old success/error to modern then/catch structure: .catch() will get a few more errors then .errors().
• Add try/catch inside catch to detect any errors parsing the response error payload including when the response doesnt include any error or flash information. In these cases log to bugsnag (throw the error again) and inform the user so we dont have silent checkout errors.

What? Why?

Related to #5192

What should we test?

We need to test checkout error scenarios:

• Redirect to cart page if insufficient stock: go to checkout with variant X in the cart, go to the backoffice and make on_hand zero for variant X, return to checkout page and click "place order", you should be redirected to the cart page with a message insufficient stock
• Try to checkout with invalid email address, for example, "ofn@org"
• Try to pay with an invalid credit card (bogus or stripe payment methods)
• Try to pay with a StripeSCA card where authentication is required for example 4000 0027 6000 3184 and fail the authentication on the stripe test page, you should see an flash error on the checkout page when you are redirected to the checkout page.

Release notes

Changelog Category: Changed
Improved resiliency of the checkout code that handles error scenarios.

[luisramos0]

I cannot find/understand what this @errors does but I dont want to remove it and break things...

[luisramos0]

tagging bug-s2 for clarity.

[filipefurtad0]

Hi @luisramos0,

Had a look at the described test scenarios:

1. Checked that the user gets redirected to cart page if the products' stock is reduced by the admin/managers during customers journey from cart to checkout. This red banner appears, with "An item in your cart has become unavailable." as well as the red text "Insufficient stock available, only 2 remaining".

• however, at this stage, the user gets "stuck" in the /cart page. Even if the number of items is reduced till the "insufficient stock" warning disappears, one does not seem to be able to proceed to checkout or to the shopfront. Here, the only way out, i.e. workaround is either a) pressing the trash-bin and removing the items from the cart, or b) using the address bar to type an address. I am pretty sure, this is not introduced by this PR - as I have observed this recently - so I will open an issue on this one.

2. Checking out by clicking the "place order" with invalid email address like ofn@ofn displays the error "Customer E-mail is invalid"

The field itself accepts an address like ofn@ofn; it does reject the email address if the @ sign is removed, thus preventing the user from clicking "place order".

3. Paying with an invalid credit card (bogus or stripe payment methods) -> Generates the red banner "Error: Your card number is invalid."

4. Trying to pay with a StripeSCA card 4000 0027 6000 3184 and fail the authentication on the stripe test page, shows the flash error on the checkout page, after being redirected to the checkout page.

• The error message displays the correct content but I am not too sure about using the underscores on this message. This makes it perhaps less readable user-friendly.

5. I added the test-case in which one completes authentication but uses a card with insufficient funds. The correct error message is displayed "Your card has insufficient funds." in the red banner, on the checkout page.

I'd say this is ready to go. I will open issues on the respective issues found on 1), an S3 maybe? I think the comment in 4) probably does not qualify as an issue, I guess.

[luisramos0]

thanks Filipe, nice testing!!!

1. I am not sure but I think there is already an issue in gh for that, please try to search for it before creating a new one.

2. yes, in stripeSCA I decided to show the user the message that comes from Stripe directly. It's not nice but it's probably more informative than a generic error message. I think we can create a lower priority issue for the stripeSCA backlog.

[filipefurtad0]

Thank you @luisramos0,

Created issues

1. Stuck on cart, if item becomes out of stock during shopping journey #5239 S3 and
2. User sees less-readable error message directly from Stripe/StripeSCA backlog #5240 S5

[luisramos0]

thanks Filipe!