Openfoodnetwork: JS errors on checkout (bugsnagJS)

[luisramos0]

Description

Since we added bugsnagJS we are seeing two common JS errors on checkout that are happening to quite a lot of users:

Just in UK 93 and 53 users respectively.

These errors do not necessarily mean the checkout is broken for all these users, but I think we need to investigate these errors as they can be causing checkout problems.

Expected Behavior

No JS errors related to checkout.

Actual Behaviour

JS errors.

Steps to Reproduce

Unkonwn so far.

type error on bugsnag:
https://app.bugsnag.com/yaycode/open-food-network-js-uk/errors/5e847cf9751a150018bc4723?filters[event.since][0]=30d&filters[error.status][0]=open

UnhandledRejection on bugsnag:
https://app.bugsnag.com/yaycode/open-food-network-js-uk/errors/5e847f9022ed50001754372a?filters[event.since][0]=30d&filters[error.status][0]=open

Severity

I'd put this as S2, it's a critical feature that may be broken.

Your Environment

links to UK prod but it's happening on other servers as well.

Possible Fix

In one case we are getting http 400 responses from the server so it should be possible to at least add some more specific debug info to the error message to help future debugging.

[luisramos0]

unhandled rejection error

So, unhandled rejections are all user errors, real examples are:

or

I am not 100% sure the user is seeing the flash message with their error in these cases. We need to watch for user reports of silent checkouts that could be caused by this error.

This is the JS explanation of unhandledrejection:
"The unhandledrejection event is sent to the global scope of a script when a JavaScript Promise that has no rejection handler is rejected"

But we do have a error handler.
This is the request:

This is the code where this 400 is caught:
https://github.com/openfoodfoundation/openfoodnetwork/blob/b92e858448ce5a0c2901be6a99b4e92a3ab08826/app/assets/javascripts/darkswarm/services/checkout.js.coffee#L19-L25

The errors are happening in all types of browsers, including up to date ones.
I cant replicate this locally...

[luisramos0]

I will improve the checkout Javascript error handling code in #5202

[Matt-Yorkley]

Are these cases covered in feature specs?

[luisramos0]

yes, checkout_spec tests a failed payment with bogus payment method. This test relies on this js code to pass.
Here spec/features/consumer/shopping/checkout_spec.rb:412

[luisramos0]

Marked this as prod test as we will have to monitor bugsnag after #5202 gets to production.
Moving to test ready and marking it as blocked until #5202 gets to production.

[luisramos0]

I hope I am using the labels and the zenhub column correctly :see_no_evil:

[luisramos0]

@RachL just shared a screenshot of a user experiencing #5080 on the checkout page.
That could mean that the bugsnag alerts of this issue are not related to the checkout JS code we are improving in #5202 but rather with, for example, stripe failing to load on the checkout page and breaking the login button...

[RachL]

A bit more info from this last user (but still no console sorry):

• he is an old customer of the hub. Was using firefox desktop for month with no issues
• he managed to login with his phone on chrome
• incognito mode on desktop didn't work as well

More info as soon as I get them....

[luisramos0]

@RachL your second screenshot where the button was displaying correctly was not on checkout so I'd say we should re-open #5080 because this issue here is for checkout errors.

• he is an old customer of the hub. Was using firefox desktop for month with no issues

This problem comes from some recent change in OFN or from a change in his Firefox (firefox version, firefox settings, firefox extensions)

• incognito mode on desktop didn't work as well

That's interesting. Usually browser extensions dont work in private mode.

[RachL]

@luisramos0 I'm sorry I've failed to move forward: the user is not responding anymore I won't have any console info. Is it worth to re-open #5080 ?
Also what's the status of this issue: How to test it in production?

[luisramos0]

I think this is a dev-test/prod-test :-)
We need to check bugsnag and see if these errors still occur: none since yesterday, let's wait a few more days and look at bugsnag again.

I think that if user reports keep coming after this week, we need to reopen 5080.

[luisramos0]

I think the situation has improved a lot, very few errors this week. I can only see two users with problems, I think they are new error messages on bugsnag. They are seeing the snail. I thought the last PR handled a 404 from the server but apparently it doesnt (the checkout server endpoint is returning a 404 :man_shrugging: ), if it keeps happening I can create a new issue to make the JS code handle the situation with a "try again message". 2 users in one week in UK is not a lot but maybe worth doing it because it's checkout.

I marked the errors as fixed on bugsnag, I'll keep this here until next week so we can check again.

[luisramos0]

There are very few JS errors on checkout :tada:
Since the 21st of April when the js improvement PR was deployed we have 3 JS errors:

• one "unknown error" that happen to only one user (edge case on the Edge browser?)
• one error where checkout returns 404 - affected 2 users
• a JS error mounting the Stripe HTML element (affecting 5 users since 21st April in UK) - this is happening on Mobile Safari, may be an edge case for that browser?

I am closing this issue as the main problem is solved.
We can open issues for these remaining issues. They will not be S2s with these number of occurrences!?