Don't miss out Virtual Happy Hour this Friday (April 26).
Try our conversational search powered by Generative AI!
AI OnAI Off
Anonymous cart sometimes not transferring on login
Hi,
Sounds like a concurrent issue to me. There is a lock to prevent the issue in ProfileModule already - do you have any custom implementation for that?
/Q
Jan 11, 2016 10:41
Hi Quan,
Thanks for the reply. The implementation is not customized, although I have the default cart and a save for later cart. I found part of the issue, but I am still having problems. I was lazy loading a new cart helper on every request. I found an article stating that the cart helper needed to be session scope. I looked at the Quicksilver site's registry and sure enough they were registering two cart helpers (one for the default and one for the wishlist) as session scope.
So I created a cart helper container object which was simply a wrapper around a dictionary of cart helpers and a method to clear them. I registered this class as per session, and my cart service contains an instance of this object.
But now I am having a different issue with the cart. When I add items to the anonymous cart and then login or register, the cart appears to have the items in it, but in the Commerce dB I see that the order group and order form id is incremented by one and has the id of the logged in user, but the line item is being deleted. This is occurrering after my mvc action completes but before the profile migrate anonymous event that I have registered in my global asax. I don't have any code in the event, I just wanted to make sure that it was getting raised. However the line item still existed in my cart for the lifetime of the session.
When I profile the SQL, I see the calls to stored procedures that insert/update the order form and then delete the line item.
So my next step is going to be decompiling the profile module class so that I can step through it.
If there are any other modules other than the profile module involved in the process of migrating the cart on login, please let me know. I really don't understand why I am having all of these cart issues. For authentication I am using cookie based identity exactly how it is implemented in Quicksilver, and it is working as expected. I am not adding roles or claims to the user when they are registering.
Hopefully decompiling the profile module will show me the issue. If anyone else has experienced an issue like this, please let me know
Thanks
Jan 11, 2016 15:57
Hi,
During profile migration, the cart is merged. The cart tied to the anonymous customer will be deleted. Its lineitems will be cloned and add to new/existing cart of logged in customer, then deleted. Those are expected behavior. What does it do wrong for you?
/Q
Jan 11, 2016 16:09
I am using Episerver Cms 9.3.2 and commerce 9.2.1. I am using cookie based Identity, and my user registration is copied from the Quicksilver demo site. User registration and login both work fine. The issue that I am having is an intermittent issue when a returning user that previously had items saved in the shopping cart logs in with items added as an anonymous user.
The issue is intermittent and this is a typical scenario.
1. User A has a line item in the cart.
2. User A logs out.
3. User A adds an item as an anonymous user to the cart
4. User A logs back in. The cart now shows 0 items
The line item still in the database, but the customerId does not correspond to any contact ids in the contact table. The Order Group name is default, the market is default but the OrderForm name is NULL
The cart is the default (using the default mediachase cart name, which is Default.) The user definately is logging in, I can see the 302 redirect and see that the anonymous user cookie has been replaced with the ASPXROLES cookie and Application cookie. The session Id is the same as when the user was ananymous. We are only using 1 market and the most basic of configurations.
I can post any additional information as needed. There is no pattern I can identify, the steps to reproduce will sometimes cause this to happen but also work successfully. The failure rate is about 50% of the time which is really frustrating. Any input will be greatly appreciated.