Openfoodnetwork: Failed checkout on FR prod related out of stock product in cart

[RachL]

Description

I have a user who cannot checkout on Guillaume's hub Le jardin de deux mains hub ID 370

She added 11 products to her cart, filed all her info, but she cannot checkout : both stripe and cash.

I cannot find her in the list of orders, she a new customer (potential guest even) with email I can give in PM.

What happens is that when clicking on the final button... nothing happens. Silent checkout fail.

Steps to Reproduce

1. Don't know yet :/
   2.
   3.
   4.

Workaround

We activated temporaly cash, but that's not it either.

Severity

bug-s1: a critical feature is broken: checkout, payments, signup, login

Your Environment

• Version used: v2.8
• Browser name and version: Firefox 73
• Operating System and version (desktop or mobile): Desktop

[RachL]

Ok so current lead: some product like turnip went out of stock while she was trying to checkout. She re-validated the cart with me on the phone, so it is possible that we have a problem of checking stock at the cart stage.

Waiting for her to call me back. Discussions on Slack channel silent-failed-checkout

[RachL]

So yes, the turnip became out of stock, this is why checkout was failing. They could checkout without turnip;

[Matt-Yorkley]

Firstly, there's nothing at all special about the troublesome turnip that broke the checkout.

I played with some specs, and it looks like:

• If a product is added to the cart and goes out of stock _before_ the user visits the checkout page: they get redirected to the cart page with an "out of stock" error
• If the product goes out of stock _after_ they've loaded the checkout page: the checkout breaks

I guess this will be more likely to occur as user activity increases.

[lin-d-hop]

The troublesome turnip made me laugh out loud.

I honestly think we are seeing this a lot this week. Since sales quadrupled in the space of 2 weeks its not surprising.

Can we fix this? ASAP?
Like... can we get it in the next release?

So many mysterious cart failures and it really really doesn't look good :-(

[Matt-Yorkley]

I need to investigate a bit more...

[Matt-Yorkley]

Something was wrong with my initial tests. Looks like the checkout handles that case fine, and we have a separate feature spec for it...

So... back to looking for theories. :disappointed:

[lin-d-hop]

Ergh, twas too good to be true

[Matt-Yorkley]

It does look related to two people buying the last units of a product at the same time...

[lin-d-hop]

That's my hunch. That's why we are suddenly seeing it loads and previously almost never.

[Matt-Yorkley]

I checked the delivery options for the hub, nothing unusual. Also the variant didn't use unit_value: 0 so it wouldn't have triggered the weight calculator bug.

So maybe some race condition when placing orders at the same time? I think I noticed our checkout concurrency test failed in a build recently, could be an indicator?

Other than that, I've got nothing, it's just a simple turnip...

[Matt-Yorkley]

Rachel mentioned this issue could be related: https://github.com/openfoodfoundation/openfoodnetwork/issues/3222

[luisramos0]

yeah, not an easy one.
I think there's something wrong with the logic of jumping to cart when products are out of stock. And the mysterious 3222 can be the cause. It's mysterious because it has code that should be dead but is alive! Spooky turnip?
I think we should get what's in the "Possible Fix" of #3222 done now.

[Matt-Yorkley]

I think we should get what's in the "Possible Fix" of #3222 done now.

Seems like a good place to start, we don't have much else to go on.

should be dead but is alive! Spooky turnip?

Sounds like a Zombie Turnip to me.

[kirstenalarsen]

There is quite a bit of history to the 'two people trying to check out last piece of stock at the same time' problem as it has been troublesome for us here in aus in the past. @mkllnk you might like to chime in here?
https://github.com/openfoodfoundation/openfoodnetwork/issues/3925
https://github.com/openfoodfoundation/openfoodnetwork/issues/4018

[mkllnk]

I don't have much to add here. We have some synchronisation that should prevent two people from checking out the same thing at the same time but if @Matt-Yorkley saw that test failing, it may not be 100% reliable.

Trying the fix for #3222 definitely sounds like a good idea. If something is out of stock but the cart doesn't recognise it because it looks at the wrong stock level then people get stuck.

[RachL]

Sounds like a Zombie Turnip to me.

Love that code name :D

[Matt-Yorkley]

OK, so next steps: add some test coverage for these cases related to #3222

[luisramos0]

There are quite a few recent occurrences of the #3222 case in bugsnag.
Maybe #5089 (fixes #3222) is all we need to do for now.
We get #5089 to production and see if this problem happens again.

I am not sure what else we can do anyway :see_no_evil:

[daniellemoorhead]

This issue's sitting in In Dev but without anyone allocated to it...does it go back to Dev Ready, or get linked to the other issues mentioned above, or get assigned to someone else? It feels weird to have an unassigned issue sitting in In Dev. @luisramos0 and @Matt-Yorkley?

[luisramos0]

if no one disagrees I think we will get #5089 to production and see if this problem happens again.
So, I am assigning to Matt (because he did 5089) and moving to test ready with prod-test label. I guess that would be the right process for this situation?

[luisramos0]

the other option is to close this with 5089 and re-open if it happens again.

[sigmundpetersen]

I don't think this will be in production until Tue 7th, so "blocked" by next deployment for now.
Please correct me if I'm wrong.

[luisramos0]

Actually, there's nothing we can check in prod after the release. We just need to wait and see if it happens again. So I am closing.