Stripe Plugin: error.entity-with-id-not-found due to order being on different channel

[yasserlens]

Describe the bug error.entity-with-id-not-found error is raised in some cases when a user is trying to place an order and pay via Stripe. It happens in the section below (service/services/order.service.js):

    /**
     * @description
     * Transitions the Order to the given state.
     */
    async transitionToState(ctx, orderId, state) {
        // ---> ERROR IS TRIGGERED ON THE NEXT LINE.
        const order = await this.getOrderOrThrow(ctx, orderId);
        order.payments = await this.getOrderPayments(ctx, orderId);
        const fromState = order.state;
        let finalize;
        try {
            const result = await this.orderStateMachine.transition(ctx, order, state);
            finalize = result.finalize;
        }

Flow of when the error happens is below:

• A user comes to the website, they're automatically assigned to a channel (which is a country-specific channel for the same store)
• The user<->channel assignment may be incorrect for various reasons.
• When the user is finally read to purchase, they may be on a different channel
• When the payment is being processed, Vendure cannot find the order number (due to it being assigned to a different channel - that's our theory of why this happens).

Ways to mitigate this:

• Temporarily switch to the default channel when trying to find the order, then switch back to the "current" channel.

To Reproduce Steps to reproduce the behavior: This would normally happen when a store has several channels. If a user is assigned a certain channel (e.g. is assigned to a global store, since storefront has no info where the user comes from) then gets assigned to a different channel when the order is placed (e.g. a local, USA channel when we know where the user is at checkout).

Expected behavior The error should not happen when an order can be found by ID or code within the same store even if in a different channel.

Environment (please complete the following information):

• @vendure/core version: 2.2
• Nodejs version: v20.5.0
• Database (mysql/postgres etc): postgres

Additional context This was discussed on Discord below https://discord.com/channels/1100672177260478564/1285979055312863263

The suggested fix was mentioned by @fainin_kev

[LeftoversTodayAppAdmin]

Hello!

Id like to reopen this issue because the above fix is causing issues when using default channel context to switch order state to ArrangingPayment but then using the channel specific context to add a payment method. If the bug is around being able to find the right order number from the correct channel, it should not be using this hack to get around it as it has other unintended consequences.

My scenario: In a multi-vendor marketplace where each store is its own channel the user is shopping within a channel and the cart is only showing items in that channel and only allows for checkouts within the context of that channel.

If the arranging payments part is done with the default context then when Vendure tries to apply the payment method it fails with this error: Error adding payment to order: ORDER_PAYMENT_STATE_ERROR. Doing everything with the channel specific context works correctly without any errors.

const paymentMethod = await this.getPaymentMethod(ctx);
            const addPaymentToOrderResult = await this.orderService.addPaymentToOrder(ctx, orderId, {
                method: paymentMethod.code,
                metadata: {
                    paymentIntentAmountReceived: paymentIntent.amount_received,
                    paymentIntentId: paymentIntent.id,
                },
            });
if (!(addPaymentToOrderResult instanceof core_2.Order)) {
                core_2.Logger.error(`Error adding payment to order ${orderCode}: ${addPaymentToOrderResult.message}`, constants_1.loggerCtx);
                return;
            }

[yasserlens]

@LeftoversTodayAppAdmin thanks for reporting this.

I think we should use the default channel elsewhere in the payment resolution process to avoid issues. @michaelbromley what do you think?

why I used the default channel "hack": It's simpler and results in less db queries. Also, at the payment resolution stage, I don't care what channel resolves the payment as long as it's resolved. I'm not losing or gaining anything from knowing that the default channel resolved payments for orders coming through channels A, B and C, for example. I'd have a much bigger problem if I fail to find the channel that the order belongs to for any reason and have the payment fail due to this, losing a customer.

Would changing using the default-channel context for orderService.addPaymentToOrder(..) help resolve the issue or introduce more side effects?

[LeftoversTodayAppAdmin]

Hey Yasser,

I think I am missing something here. In the example multi-channel marketplace, one order can have orderlines (items) from different channels and there is a strategy to handle that order where each item is fulfilled by the respective channel. What do you mean by switching channels?

Maybe @michaelbromley can help you out, but the context should be set by the user, if you want to resolve your order with the default channel then for that particular call maybe you can remove the vendure-token in the request header, which defaults to the default channel, otherwise provide vendure-token in the header to handle it on a per channel basis like I am doing now. Both should work and the plugin should honor whichever channel is set in the request instead of hardcoding to default always.

[yasserlens]

@LeftoversTodayAppAdmin Regardless of which channel the order lines belong to - I'm not sure I understand why the payment resolver has to be channel aware to process a payment?

Having the payment resolver be on the default channel allows it to process any payment regardless which channel the Order or OrderLines in it belong to.

I understand how channels work - but I'm not sure I understand your usecase. @michaelbromley would be in a better position to evaluate how to resolve the issue you're reporting.