Issue with Order Creation Across Multiple Browsers in Next.js Starter & Medusa Admin

[fathom vapor]

Hey everyone,

I've encountered a bug related to order creation and would really appreciate any insights or solutions you might have.

Environment:
Using the latest versions of Next.js Starter and Medusa Admin.
Encountered across different private browsers and tabs without any cookies or cache.

Steps to Reproduce:

1. Register a new customer account and log in.
2. Open +-three different browsers, ensuring they are free of cookies and cache.
3. On each private browser tab, attempt to create orders as anonymous users.
4. Meanwhile, add items to the cart and proceed to checkout with the freshly registered customer on the storefront.
5. After completing the address section in the checkout for the anonymous users, their sessions are unexpectedly overwritten with the email of the newly registered account, other data from address section remains the same.

Issue:
The anonymous sessions in the checkout are being overwritten by the email of the newly registered account after completing the address section.

Questions:
Has anyone else experienced this issue?
Can someone provide guidance on how to resolve this problem?

Thank you in advance

[bronze surge]

With private browsing cookies and sessions are handled but deleted on closure. I am not 100% if I understand what is the problem. Can you provide a step by step as I was unable to reproduce with the above steps

[fathom vapor]

Problem:
Under pressure and with multiple requests for checkout and user assignment to cardId, it occasionally happens that several different orders are assigned under the same account. I have discovered that this issue also occurs on the official demo website https://next.medusajs.com/. Unfortunately, it is more challenging to consistently reproduce this problem exactly every time. Because I don't know exactly what causes this issue.

Steps:

1. Open the demo on multiple different browsers (Chrome, Firefox, Safari) to avoid merging cart and customer cookies.
2. On the first browser, register a new customer and add a product to the cart. Fill out only the shipping address and stop before clicking on “Continue to payment”.
3. On the second browser (as an unlogged user), add a product to the cart and fill out a different shipping address and a different email. Do not finalize the order creation, but leave the data filled in the form and do not click on “Continue to payment”.
4. On the third browser, perform the same steps as in point 2, but use another different email.
5. You now have three different forms prepared.
6. Try to submit all three shipping forms one after another as quickly as possible without any delay to test server load.
7. Check if the correct email you entered is associated with each saved order.
8. Notice that sometimes the wrong email gets incorrectly associated with orders.

I have noticed that there must always be at least one freshly registered customer (1 of the multiple requests), with no previous orders, and without assigned cartIds and payment sessions.

[hollow sundial]

But multiple open browsers in incognito mode share the cookies

[fathom vapor]

Sorry, I am using multiple different browsers in incognito mode, Arc, Chrome, Firefox and Safari.

We are developing an ecommerece for client.
We have dev deployed on netlify and railway.
One day I submitted an order with my customer account and also at the same time our tester submitted different order with different account.
We were using different computers and network.
And both orders were assigned to my account. - This should never happen.

Since then I have been trying to reproduce this error which also occasionally happens to me on the official demo website of the Next.js Medusa starter.

[bronze surge]

this sounds strange to be honest, will do some tests

[bronze surge]

i am unable to reproduce this behaviour

can you restart the backend and share the output please?

I suspect you do not have redis configured

[fathom vapor]

I was able to capture this strange behavior in the official demo example in two videos. As you can see in the videos, cookies are cleared. Sometimes it behaves this way and sometimes not, it's hard to say exactly what might be causing it and how to exactly reproduce it.
Anyway, could there be an error with the cache somewhere? Whether in NextJS Server Actions or in MedusaJS? Because if I'm not mistaken, after clicking on "Continue to payment", the cart object gets updated through the Medusa backend.
Or am I missing something?
Test1: https://www.youtube.com/watch?v=ASqTf6jrbXs
Test2: https://www.youtube.com/watch?v=X5vDgSpe_bE

[hollow sundial]

I have initialy thought that would be some issue with you not setting up Redis and server side cache. But I cheched the core code and Redis Cache is used only in Price Selection Strategy I believe.

My guess now is that it is indeed an issue with Next.js cache and how the starter is built.

Disclaimer: I have not once created a website with the new app router. I still develop new projects with the old Nextjs pages router. My knowledge about the new app router, RSC and server actions is still minimal and just based on some sparse docs reading. Keep that in mind as I might be wrong.

So my guess is all the fetches are being cached on the server and then actions use revalidateTag to invalidate the customer tag: https://github.com/medusajs/nextjs-starter-medusa/blob/38858dbcf3a3cc21cbf166634deafdd1c833ed30/src/modules/account/actions.ts#L79
From docs:

revalidateTag only invalidates the cache when the path is next visited. This means calling revalidateTag with a dynamic route segment will not immediately trigger many revalidations at once. The invalidation only happens when the path is next visited.

That would explain why you see old, cached value from the first window in the second window. Then it invalidates in the background similiary to Stale While Revalidate.

But I feel like caching should not be used for customer logging in etc at all, as it's server side (?).

Still keep in mind that's just my quick guess from a quick look around

[bronze surge]

this is not the problem

the _medusa_cart_id cookie is the issue

open 2 seperate browsers

clear the cookies

open the store in both browser

open dev tools applications cookies

should eb empty

add the same product into the cart

the cart id will be identical in both browsers

@fathom vapor what browsers are you using in the video?

[hollow sundial]

I can't reproduce above steps. Firefox and Chrome

[fathom vapor]

Top left is Firefox, top right is Chrome, bottom left is Opera, bottom right is Edge

[bronze surge]

i managed once on the demo

@fathom vapor can you please test in your local and provide a video where we can see the dev console cookies as well as you local backend logs?

[hollow sundial]

You should also know that session cookie is stored on the backend domain and empyting just the frontend domain won't do anything for that cookie. But I don't know how much that relates to the new next.js starter.

[fathom vapor]

https://youtu.be/AK96Ydg6XNY
This video includes a dev console and MedusaJS backend logging. I have also added cart creation and update subscribers that print out the cart ID, customer ID, and email.

I should also mention that before recording this video, I registered a new customer ([e-mail]) in a different browser, Arc.

The browser in the video is Safari, and the user is not logged in.
However, after clicking "Continue to payment," it still switches to the [e-mail] email. Additionally, as you can see in the Medusa console subscriber, Medusa adds this customer to the new cart/order creation. - (completely different session)

[hollow sundial]

I still would suspect the Next.js cache, but it is unknown territory for me. You have enough reproduction to file a bug report on github. Post an issue.

[bronze surge]

So we need to ser the POST store/cart payload

Also noticed 2 subs for cart customer updated

Can we check what are those?

[fathom vapor]

request cart data: cart_01HRA06F29XG2X6P2M6JX8QMK2 { shipping_address: { first_name: 'ggqwrweq', last_name: 'gewqegwq', address_1: 'gewqegwq', address_2: '', company: '', postal_code: '12322', city: 'gwqe', country_code: 'cz', province: '', phone: '123123123' }, email: '[e-mail]', billing_address: { first_name: 'ggqwrweq', last_name: 'gewqegwq', address_1: 'gewqegwq', address_2: '', company: '', postal_code: '12322', city: 'gwqe', country_code: 'cz', province: '', phone: '123123123' } } response cart data: { object: 'cart', id: 'cart_01HRA06F29XG2X6P2M6JX8QMK2', created_at: '2024-03-06T13:45:40.153Z', updated_at: '2024-03-06T13:46:03.911Z', deleted_at: null, email: '[e-mail]', billing_address_id: 'addr_01HRA076AP6JTV0M8X7Y89EMQJ', shipping_address_id: 'addr_01HRA06F29922VDXJ2D6JBFMQF', region_id: 'reg_01HQTM1VR6JN6SZ7JBMKRRX4R7', customer_id: 'cus_01HRA067V0AGRF1Q1HMKS7SVX6', payment_id: null, type: 'default', completed_at: null, payment_authorized_at: null, idempotency_key: null, context: { ip: '::1', user_agent: 'axios/0.24.0' }, metadata: null, sales_channel_id: 'sc_01HQTM1RM73ZEEKEXHW8R6W6RB',
This is console log out from Frontend - updateCart function - request payload is correct but then the response from updateCart is with different data, customer_id of freshly registered user with cartId gets incorrectly assigned to a cartId.
This time there was only 1 sub for cart customer update.

[fathom vapor]

Yes, probably will do. Thx

Also I noticed when I register a new customer and then add a product to the cart, subscribers look like this:
::1 - - [06/Mar/2024:13:53:28 +0000] "GET /store/products?id%5B0%5D=prod_01HQTME6Y1PYDDVP8SYHPVJ1HS&region_id=reg_01HQTM1VR6JN6SZ7JBMKRRX4R7 HTTP/1.1" 200 2293 "-" "axios/0.24.0" info: Processing cart.created which has 1 subscribers info: Processing cart.updated which has 1 subscribers info: Processing cart.updated which has 1 subscribers info: Processing cart.updated which has 1 subscribers info: Processing cart.updated which has 1 subscribers =====START CART UPDATE SUB===== CartID: cart_01HRA0MQZK5TRY1HE364KEV42M CartCustomerID: cus_01HRA0MCPHPRABB8J63JMB48T0 CartEmail: [e-mail] ======END CART UPDATE SUB====== =====START CART CREATE SUB===== CartID: cart_01HRA0MQZK5TRY1HE364KEV42M CartCustomerID: cus_01HRA0MCPHPRABB8J63JMB48T0 CartEmail: [e-mail] ======END CART CREATE SUB====== =====START CART UPDATE SUB===== CartID: cart_01HRA0MQZK5TRY1HE364KEV42M CartCustomerID: cus_01HRA0MCPHPRABB8J63JMB48T0 CartEmail: [e-mail] ======END CART UPDATE SUB====== =====START CART UPDATE SUB===== CartID: cart_01HRA0MQZK5TRY1HE364KEV42M CartCustomerID: cus_01HRA0MCPHPRABB8J63JMB48T0 CartEmail: [e-mail] ======END CART UPDATE SUB====== =====START CART UPDATE SUB===== CartID: cart_01HRA0MQZK5TRY1HE364KEV42M CartCustomerID: cus_01HRA0MCPHPRABB8J63JMB48T0 CartEmail: [e-mail] ======END CART UPDATE SUB====== ::1 - - [06/Mar/2024:13:54:18 +0000] "GET /store/regions HTTP/1.1" 200 727 "-" "axios/0.24.0"
Looks weird

[hollow sundial]

Either something with customer sessions or the cache. I can't think of anything

[tall yoke]

@fathom vapor this is because of another cookie called _medusa_jwt. Underneath, when you are doing POST on the cart, middleware fills email address using this cookie, so that's why it is being done automatically.

[fathom vapor]

@tall yoke - This is understandable for logged in customers. But this happens even for those who are not logged in...
I tried calling the MEDUSA API locally at http://localhost:9000/store in Postman without any frontend.
After calling this url a 'Cookie: connect.sid=s%3Av8CsKFYnQ6NH2eTdXHsXRUT-vbymg_KP.jlsj%2FoHy%2B2XroEQJqJ6ZXyqudC8jo%2Fn0diU9xyUNP4M' cookie automatically gets assigned to headers.
This also happens for non logged in customers and automatically after calling POST requests to create a cart, a customer gets assigned to this cart.
When I call the cURL method to create a cart without the Cookie: connect.sid, a cart is created without a customer

• We have REDIS set up in production

[tall yoke]

_medusa_jwt is stored into local_storage in browser (not sure if it is the same as cookie) - probably incognito mode takes it anyway and use it. This is only my suspicious.

I know only that _medusa_jwt is used to authenticate the requests to API store and middleware takes all inforamtion from there to proceed after POST requests (some of them like filling email are being done automatically by backend)

[hollow sundial]

The cookie is always created by the backend and is stored in browser on the backend domain. You can just visit your backend domain in incognito mode and a session and cookie will be created. Here are the settings of the session https://github.com/medusajs/medusa/blob/fcb03d60ea922f413a2879b70802549098780812/packages/medusa/src/loaders/express.ts#L30

[fathom vapor]

I set the saveUninitialized value session_option to false and its still happening.
I found out that assigning a different customer to a different cart happens only in the checkout phase, where I send a request to updateCart with delivery address, email, phone.. After calling this updateCart request, cart is returned with different customer. Only there.
The creation of a cart does not cause this.
Anyway I will continue to investigate this updateCart request

[bronze surge]

lets check your packages

Maybe one of them had an issue with earlier version