Cart adapter for customer data storage cache missing from server side, problem while using headless such as PWA, AEM

[tuyennn]

Preconditions and environment

• Magento version: 2.4.x

Steps to reproduce

1. Add some products to cart.
2. Perform checkout steps with address, shipment, payment
3. Switch between some available shipping methods
4. Perform getcart graphql query {cart(cart_id: String!) {Cart}} to get current cart information
5. Observe the selected_shipping_method with last state on step 3

Expected result

• selected_shipping_method consistent while performing get cart graphql and last selected state

Actual result

• selected_shipping_method inconsistent while performing get cart graphql and last selected state
• cart-data information could not be accessed from GraphQl, restAPI for current quote

Additional information

• Observe the mage-cache-storage.
• The cart-data stores cart information in the customer's local storage (localStorage) without saving it on the server.
• The cart-data can be accessed by other services, such as GraphQL and REST API, to retrieve the current quote. This is important because multiple services can use the same resource and transfer customer data between headful and headless systems, such as AEM pages and Luma-based stores.
• For reference, this cache is implemented in the following file: https://github.com/magento/magento2/blob/2.4-develop/app/code/Magento/Checkout/view/frontend/web/js/model/cart/cache.js, which stores cart data in the customer's local storage without saving it on the server.
• When a customer selects a shipping method during checkout, Magento calls the REST API endpoint rest/V1/guest-carts/{cartId}/totals-information or /rest/default/V1/carts/mine/totals-information. However, this does not save the selected shipping method or totals at the server level. Instead, only the cart data (cart-data) is cached in the customer's local storage.
• Suggestion: Implement server-side caching for the selected totals and shipping methods. This would allow other services to access the cached totals, ensuring consistency across different systems.

Release note

No response

Triage and priority

• [ ] Severity: S0 - Affects critical data or functionality and leaves users without workaround.
• [ ] Severity: S1 - Affects critical data or functionality and forces users to employ a workaround.
• [X] Severity: S2 - Affects non-critical data or functionality and forces users to employ a workaround.
• [ ] Severity: S3 - Affects non-critical data or functionality and does not force users to employ a workaround.
• [ ] Severity: S4 - Affects aesthetics, professional look and feel, “quality” or “usability”.

[m2-assistant[bot]]

Hi @tuyennn. Thank you for your report. To speed up processing of this issue, make sure that the issue is reproducible on the vanilla Magento instance following Steps to reproduce.

• For more details, review the Magento Contributor Assistant documentation.
• Add a comment to assign the issue: @magento I am working on this

• To learn more about issue processing workflow, refer to the Code Contributions.

  Join Magento Community Engineering Slack and ask your questions in #github channel. :warning: According to the Magento Contribution requirements, all issues must go through the Community Contributions Triage process. Community Contributions Triage is a public meeting. :clock10: You can find the schedule on the Magento Community Calendar page. :telephone_receiver: The triage of issues happens in the queue order. If you want to speed up the delivery of your contribution, join the Community Contributions Triage session to discuss the appropriate ticket.