Hey @vc-ca thanks for the detailed report and your patience here.
I can’t say for sure, but the behaviour you’re describing typically happens when the cart query only requests a single line due to pagination.
In the Storefront API, cart.lines is a connection and you must pass lines(first: N), otherwise a small default like first: 1 (or a variable that defaults to 1) will only return one item even though the cart contains more.
Can you share your cart query requests here and confirm if you’re querying for multiple lines (for example, lines(first: 50))?
Another thing that could potentially contribute to this if cart request isn’t using the full cart ID including the ?key=…; dropping the key or using an older token can lead to confusing results.
If you’re on Hydrogen, I’d also make sure you’re updating the cookie/header right after mutations. Another thing to check, on refresh, is to see that you don’t have any background logic that “replaces” lines (for example, a cartLinesUpdate that only sends a subset), which would make it look like a query issue.
If the issues persist after checking the above, no worries, if you can share the exact cart query (selection set and variables), your mutation and query sequence, and run the same cart in Storefront GraphiQL with lines(first: 50) and then share the x-request-id from the response headers we send back and timestamps, I’m more than happy to take a look at the issue in our logs and we can potentially escalate this to our product team.
Thank you for the detailed response. I’ve investigated all your
suggestions and from what I can tell, this is a genuine API bug, not a configuration issue.
Here’s what I’ve verified:
Cart Query Configuration
We ARE using lines(first: 100) in our query:
fragment cart on Cart {
id
checkoutUrl
cost { ... }
lines(first: 100) { # <-- Requesting 100 lines
edges {
node { ... }
}
}
totalQuantity
}
Cart ID with Full Key
We ARE preserving the complete cart ID including ?key= parameter:
Cart ID used: gid://shopify/Cart/hWN1gRXMwmskUxSyyDa71xzd?key=c9c4bea56291ba03ba383d099ece0e9f
Reproducible Bug Evidence
Here’s a complete sequence showing the bug:
Step 1: Add 4 items via cartLinesAdd
Mutation Response:
Not a Pagination Issue
The totalQuantity field itself returns 1 instead of 4, proving this isn’t a
pagination problem. If it were pagination, totalQuantity would still show 4?
No Background Updates
We have no cartLinesUpdate or cartLinesRemove operations between the mutation and query. The sequence is:
cartLinesAdd (returns 4 items)
Page refresh
cart query (returns 1 item)
Request for Investigation
Could you please investigate with these specifics:
Thanks @vc-ca for the followup and the extra details (including the repro steps.), really appreciate this.
It does seem like something odd is happening between the line items being added and the query. I haven’t been able to replicate on my end though on my test shop. Here’s my current flow:
I run a cartCreate mutation via the storefront API
Then, I run a cartLinesAdd mutation like this:
Summary
mutation cartLinesAdd($cartId: ID!, $lines: [CartLineInput!]!) {
cartLinesAdd(cartId: $cartId, lines: $lines) {
cart {
id
totalQuantity
cost {
totalAmount {
amount
currencyCode
}
}
lines(first: 10) {
edges {
node {
id
quantity
merchandise {
... on ProductVariant {
id
title
product {
title
}
}
}
}
}
}
}
userErrors {
field
message
}
}
}
Variables:
Summary
‘’’
{
“cartId”: “gid://shopify/Cart/id-here”,
“lines”: [
{
“merchandiseId”: “gid://shopify/ProductVariant/variant-id-here”, ## This is adding a new variant, not just adjusting the quantity, to clarify!
“quantity”: 5
}
]
In the returned response, I am able to see the newly added line items. If I just query the cart as well with a cart (id:) query, the new lines show up, so it is strange that it’s seemingly not taking.
One thing I just wanted to check, are those items part of any bundles that might appear as a single line item? Just trying to narrow down the issue. If not, happy to keep looking into this for sure.
If you’re still seeing the issue pop up, if you could share the x-request-ids from when you make an example cartLinesAdd mutation and then one for when you make the standard cart query, I can trace that exact flow in our logs and get in touch with our product team to investigate further.
Hope to hear from you soon, thanks again for your patience on this as well, really appreciated!
The cart query is returning a stale/cached state showing previously
deleted items. This suggests the query endpoint isn’t reading from the
same data source as mutations, possibly hitting a stale cache or read
replica.
Thanks @vc-ca appreciate you sending these my way. I’m going to reach out to our product team for you now so that we can investigate this further internally and I’ll reach out as soon as I can confirm a fix/expected behaviour or share next steps.
Hey @vc-ca, I was able to work with some folks internally on this, and we may need some more info from you. Would you be willing to work on this with me in direct message on the forums here? I can set that up on my end (we may need some more shop-specific info that we don’t necessarily want to share publicly!).
One other thing we noticed in our troubleshooting is that it looks like you’re using API version 2024-01. Could you try replicating this issue using API version 2025-07 (the latest API version) and letting me know if the issue persists? I’m just wondering if the issue pertains to that older API version being used there.
Hope to hear from you soon, thanks again for the patience on this, it’s really appreciated.
After your suggestion to test with API version 2025-07, I did more digging and found the root cause was a caching conflict in my implementation.
The Shopify API is working perfectly.
The Problem:
My shopifyFetch function had a hardcoded revalidate: 600 (10-minute cache) in the Next.js fetch options, but I was also passing cache: 'no-store' for cart operations. This conflict caused Next.js to serve stale cached responses.
Hey @vc-ca, glad everything is working for you now and thanks for sharing your solutions here with the community. Let me know if I can help with anything else as always!
