Openfoodnetwork: Grumpy cat (http 422) trying to access the shopfront

[Matt-Yorkley]

Error in OpenFoodNetwork UK

ActiveRecord::RecordInvalid in enterprises#shop
Validation failed: Distributor or order cycle cannot supply the products in your cart

View on Bugsnag

Stacktrace

app/controllers/enterprises_controller.rb:74 - reset_order

View full stacktrace

Created by Admin OFF via Bugsnag

[luisramos0]

I created the issue in bugsnag.

80 events, 33 users impacted in the last month (in the uk only).

S2?

[luisramos0]

I think this is people switching shops with products in the cart, the products in the cart from the previous shop make the new cart blow up, or something like this.

[Matt-Yorkley]

So from the stacktrace it looks like it's related to validations failing on a _collection_ that's related to items in the cart.

I have a strong suspicion it could be related to this (but I could be wrong): https://github.com/openfoodfoundation/openfoodnetwork/issues/5335

Basically a product has been soft-deleted, which means it's variants have been soft-deleted, at which point the associated stock_item for each variant has been hard-deleted. Variants validate the presence of a stock_item when they are saved or updated, so any attempt to touch on a soft-deleted variant that involves saving it or checking #valid? on it will throw an error...

[Matt-Yorkley]

We probably need some feature specs for cases where:

• a product in an active order cycle is soft-deleted after it's been added to the cart, and then the user a) visits the cart page and b) changes to a different shop
• a product in an existing completed order is soft-deleted, and then the order is cancelled via the UI

[lin-d-hop]

Food Lochaber grumpy cat

[lin-d-hop]

You can see a case of this happening at 58 mins into this video:
https://drive.google.com/file/d/17__IirGj4BYWVh5L9hkR1rp3tzI87Dol/view?usp=sharing

This was not related to changing shops. It was a flow from checkout back to the shop.
It is likely the cart contained a soft-deleted variant.

[luisramos0]

@Matt-Yorkley it's very probable that this is being addressed as part of the cart work you are doing in #5358, right?

[Matt-Yorkley]

It's possible, but we'll need to take another look after #5358. The bug is closely related but in a different part of the app, it might need some additional tweaks. It'll definitely need additional specs.

[Matt-Yorkley]

Ok, it looks like at app/controllers/enterprises_controller.rb:74 - reset_order we call order.save!, I think this method is called after an order is placed and the customer returns to the shop, or when changing shops.

[Matt-Yorkley]

I've more or less figured out this edge case, but I'm having trouble replicating the specific path in tests. I'll move this back to dev ready and maybe someone else can have a look.

I've left some explanatory notes here: https://github.com/openfoodfoundation/openfoodnetwork/compare/master...Matt-Yorkley:enterprise-controller-stock

[luisramos0]

Hey @lin-d-hop , the video was really helpful, I can replicate this!
All you need is a shop with 2 open OCs. Select one of the OCs and add some items to the cart.
Go to the backoffice and close the OC you have the cart on. When you try to reload the shop page, it will TRY to automatically select the other still open OC and fail with this error.

This does not happen if you only have a cart in one OC and close that OC, in that case, if you go to the shop you will see this message:

Also, initially I thought this bug would happen even if the open OC contains the items in the cart from the other closed OC. But now I see that if the open OC contains the items in the cart, the cart will just be moved from one OC to the other. So, to replicate the problem the cart must contain a product that is not in the open OC, only in the closed OC.
This is not consistent with the change of OCs in the OC selector because if you switch OCs the cart will always be emptied (even if all products in the cart are sold on the newly selected OC).

[filipefurtad0]

That's it @luisramos0,
I've reproduced it the way you describe - awesome :tada:

It's interesting to observe that if two open OCs have the same products, and one of them closes before checkout, the products on the cart are automatically allocated to the OC remaining open, and neither the grumpy cat, nor warning is displayed.
That makes me wonder how and if having an alternative OC with the same products influences the outcome described in bug #5372 ... I'll investigate this soon and report there.

[luisramos0]

ah, interesting but the code that moves the OCs around and works if products are "compatible" between OCs is in the shop controller, it wont be used if you only load the checkout page. The checkout will probably break anyway.

[filipefurtad0]

...Yup! Just checked: breaks anyway, despite having the same products on another open OC :-)