Developer forum

Do you have a Notifications.Ecommerce.Stock.StatusChanged order checkoutdoneorderiscomplete notifcaton?

Does it use Common.Context.Cart?

Other custom code or notifications with call to  Common.Context.Cart?

NP

Hi Nicolai,

Nothing custom like that, as you can see by the attachments. You may find the LI assembly name odd, but that's how we had it back then.

Since this month this happened to 4 orders but we have a few of those since January 6th of this year (another attachment). Looking back in time I don't see anything meaningful that was done before that period (like an upgrade or dll deployment) that could be causing it.

Can you think of a way to track this down further?

Best Regards,

Nuno Aguiar

Nope. Some code tries to update a cart that is now an order... I would look for Common.Context.Cart in templates and all of your source code.

Will do, thanks

Nicolai,

We've found further information about this. We had another site with the same issue. In fact, we weren't aware that Nuno had the same issue until we discovered this forums post.

The issue has occurred with 3 different payment providers. One is Authorize.net, and the other two are two separate versions of ChargeLogic (Credit Card and ACH versions). These are on two separate sites. We don't believe it's from custom code since we didn't see custom code that runs at that time. 

We noticed that you've recently checked in code to add additional debugging in this section, so you may be troubleshooting this for another situation too, so hopefully this helps all of us out.

Mário and I created a video here. 

Let us know if you have any questions, and hopefully at least the endless loop issue is solvable with this information. 

Scott

Hi Nicolai, 

Any update on this from Scott? We have a customer looking for a solution soon.  

We have looked into the code where these messages are coming from.

It does not seem to be the checkout handlers that causes this. But we can see GetCart in common.context has a dual call to get the cart from session that could be the cause. But it arrises from something else that fiddles with the cart context. We have noticed a number of SetCarts in your template code which could be the issue.

We have created a bug and a change of implementation related to this on #9373, https://dev.azure.com/dynamicwebsoftware/Dynamicweb/_workitems/edit/9373

You can see the proposed change here: https://dev.azure.com/dynamicwebsoftware/Dynamicweb/_git/Dynamicweb/pullrequest/5510?_a=files

Since this is a relatively big change of behavior we cannot merge this down. So it will be released on 9.14

Hi Nicolai,

I see that #9373 is closed, in what version this change be released?

BR, Mario

Is there any update on this fix for #9373? We have a customer waiting on this. It looks like it was closed but we don't see any release info. 

Fix has now been merged and is available in the latest Dynamicweb.Ecommerce package from https://www.nuget.org/packages/Dynamicweb.Ecommerce/1.14.25

It will also be included in the upcoming 9.14.4 release

/Morten Buhl, DW

Hi Nicolai,

We were able to figure out the root cause today. This came up in a 3rd project and were able to get a debugger on it. The core issue is that Dynamicweb.Ecommerce.Common.Context.Cart doesn't just read the current cart, but it clears the pricing cache and does a save, causing it to reach out to the ERP for the pricing. The call to the ERP needs to determine the URL which needs to use Context.Cart, leading to the loop. The platform attempts to write the cart to session but the endless loop occurs first so the SetCart() never successfully completes before it attepts to load prices again, and so it continues.

We created a video stepping through it to show why it occurs and where. 

https://www.dropbox.com/s/l5acg5opgs2vyz0/2022-11-22_13-43-23.mp4?dl=0

One minor note is that in the video I said that we could create a workaround by caching the URL, but that wasn't correct. We can't get it to complete the first time to be able to cache it. We created yet another workaround, but it's not very pretty and it's temporary until there is a platform solution.

Thanks,

Scott

That code in i.e. UrlHandler.cs does not look like the code we have in our default live integration code. What version is that?

The only time where LI is getting Common.Context.Cart is when you have multiple endpoints in the format of  [EndpointName];[Field];[Value] where the field is named "Order.*"

Hi Nicolai,

Yes, that's our version. I'm not sure if that came from your version years ago or if we customized this (years ago), but it's to support having different ERP URLs depending on the ShopID. We don't use it often but we have a couple sites that depend on that info from the cart.

We also have what you mentioned where the field is Order.*. 

Thanks,
Scott

From what I can see, the price cache is only reset in situations where the cart is loaded from database if the user has been away for a while.

But will you look into your code to not use common.context.cart in your cart loading?

Hi Nicolai,

That sounds right. We could start with a different customer who didn't have any items in the cart and it would cache the URL, and then we could switch to the other user with items in the cart and it would be ok for 5 minutes. After 5 minutes, we would refresh the page and then the issue would occur.

I'm not sure how to avoid the common.context.cart. We only have about 2 projects that need that feature, but if we don't want to have to branch to have two versions. btw, I'm not sure why we're only noticing is more recently. I haven't dug into that yet.

The only solution that I know to support this is to:

• Have a setting to turn it off, for performance benefits.
• To support when it's turned on, we would need to copy the code from the platform that gets the active cart but not do the clearning price cache and save(). It would be ugly to have to replacing that code, but it would be a solution.

The workaround for now, since this project doesn't need the cart, is to replace common.context.cart with null. That works well, but we can't merge that change into our main project, so we're having to keep a temporary build for this project for now.

Thanks,
Scott

Hi guys,

Any solution to this issue?

We found it recently on a Rapido project that has been upgraded from 9.12 to the latest 9.14.
According to this thread, the bug was supposed to be fixed in 9.14.4.

In our case, it shows when a customer logs in after a period of time.

Any workaround? The customer is pretty annoyed that an upgrade introduced a serious error like this.

Thank you,

Adrian

If you read the entire thread you will see that the problem probably arises from a verion of Live integration that calls Context.Cart too often and that might be what you need to look into. Or you might have some other things in custom code causing the loop.

If you have things that calculate prices that during the process tries to call context.cart, you will have the problem. Because to get a 'stale' cart from database, the price needs to be calculated using the price provider - that will then try to load the cart etc.

BR Nicolai

Hi Nicolai,

I admit this case may be a bit different than mine.

In my case, the CartID that is saved in the cookie of the user, is no longer available when the user logs in.

I don't think that it has a direct connection to live integration.

In our case, there are situations where 2 different users are sharing the same credentials. If one of them starts a cart and the other one finishes it, the first one will get an error when logging in. This did not happen before the upgrade. At least according to what the customer said.

It cloud have something to do with a check of the cart before loading it from the cookie.

If you're saying that I should look into the Live integration code, I will.

Thank you,

Adrian

Adrian's scenario is also triggered when you  delete an order

1. In the frontend, add something to the cart
2. In the backend, find the cart and delete it
3. In the frontend, reload the cart.

Actual results:
Exception: Recursive call: The Context.GetCart() is not a cart and cannot be updated.                             
Reloading the page won't help and the user is stuck until they clear their cookies.

Expected results
Since the cart is unrecoverable, would it make sense to the clear the Cart ID cookie here?

Imar

Hi, 

new task #13708 has been created. Thanks.

BR, Oleg QA

Hi

The task #13708 Context.GetCart() is now fixed
Get this latest release from the download section 

https://doc.dynamicweb.dk/downloads/dynamicweb-9

Kind Regards
Dynamicweb Care Support
Kristian Kirkholt