Openfoodnetwork: Impossible to access an order (neither for manager or super admin)

[myriamboure]

Description

On French instance, the order n° R477874472 is inaccessible neither by the hub manager nor super admin. When we click on "edit" or on the order number we get the snail with the following error :

The order appears as "credit owed"

and when I click on "credit owed" I can still access the "payment" sub menu of the order:

but even from there if I click on "detail of the order" I get the snail and can't access it.

I asked the hub manager what she did, as apparently the customer paid through Stripe the order, and something was taken out of the order afterward so the manager wants to refund some money. I suspect the issue comes from the way the hub manager has withdrawn products from the order, that might be connected to the "ability to delete a line item" issue ? Waiting for hub manager answer.

Meanwhile, if you have an idea... The hub manager said she was blocked to pay back the customer, I shared the possibility to access the payment section so hopefully that will unlock her, but I think not being able to access an order is an S2.

Expected Behavior

Hub manager can access and edit an order

Actual Behaviour

She can't for a specific order for some unknown reason

Steps to Reproduce

No idea how to reproduce for now... waiting for hub manager answer on what she did.

Context

The hub manager contacted me.

Severity

S2

Your Environment

• Browser name and version: Firefox
• Operating System and version (desktop or mobile): Ubuntu
• OFN Platform instance where you discovered the bug, and which version of the software they are using : French, v2.2.1

[myriamboure]

Apparently she deleted some products through "bulk order management" as she already couldn't access the order, from the beginning.

[luisramos0]

I think you mean "remove product from order" and not "delete product", correct?

[myriamboure]

Apparently this order, from the beginning she never could access it.
In BOM she selected multiples products she needed to remove from orders and clicked on "action" / "delete selection" @luisramos0

[myriamboure]

This is the only order affected in the order cycle, she did the BOM deletion for multiples orders, and other orders were not affected, and anyway this order was already inaccessible before she delte products in BOM.

[kristinalim]

It seems that a variant (the actual variant) which the customer added to their order was deleted at some point. The product is also deleted. @myriamboure FYI the product is "pommes de terre Anais". Does the user by any chance remember the state of the order when this product was deleted?

There result is there is a shipment item for the order that has no variant reference, and this is causing the error. I'll investigate further. @luisramos0 Just let me know if you have an idea.

order.shipment.manifest.map { |item| item.variant.try(:id) }
# => [14352, 10625, 10996, nil, 10920, 10922, 11437, 10967, 10601, 10607]

order.line_items.map(&:variant_id)
# => [14352, 10625, 10607, 10601, 10967, 11437, 10922, 10920, 14894, 10996]

This is the related HTTP 500 event on Bugsnag for France:
https://app.bugsnag.com/open-food-france/open-food-france-prod/errors/5d4051e0cb6ff1001c482f40?filters[event.since][0]=30d&filters[error.status][0]=open

And this is the stacktrace:

[luisramos0]

yeah, it's the continuation of #3903

@kristinalim I think we will need to make the shipments connection to the variants see deleted variants as we did for line_items here.

The challenge I think is that, in shipments, the variants are inside the manifest structure...
maybe we need to bring shipment.manifest to OFN and use a variants scope that includes deleted variants
https://github.com/openfoodfoundation/openfoodnetwork/blob/75c7e0b939e1b195f744ead87329c80c003bf6f5/app/models/spree/shipment_decorator.rb#L21

[luisramos0]

what I say above is applicable to closed orders in the past, for recent orders, not shipped r in open OCs, we may need to rebuild shipments when product is deleted?

[kristinalim]

Thanks @luisramos0 - that's really helpful.

About rebuilding, maybe we should not? AFAIK, in the perspective of existing orders, the variants should always exist while the orders are still being processed.

I was worried that shipment.manifest does not actually have the variant_id in the sample data anymore, but it does: :relieved: (Shipment#manifest uses inventory_units.)

order.shipment.inventory_units.map(&:variant_id).uniq
# => [14352, 10625, 10996, 14894, 10920, 10922, 11437, 10967, 10601, 10607]

[kristinalim]

@myriamboure FYI, this issue is actually already resolved by @sauloperez in PR #4065 for #3903. The resulting error was different because of the state of the order when the variant/product was deleted, but the change already addresses this too. The PR is already merged in master so it should be in the upcoming release.

I still need to finish adding automated test coverage for this to avoid regression. Will do so in the morning.

[luisramos0]

ah, brilliant!

[sauloperez]

Thanks for the specs @kristinalim :muscle:

[RachL]

This is solved by v2.2.2. So I'm closing this.