Checkout UI Extension - useApplyCartLinesChangeSuccess Response But No Actual Cart Update After Shipping Country Change, possible conflict with auto-focus on checkout fields

Extensions
1

Title: applyCartLinesChange succeeds but cart doesn’t update reliably when shipping country changes — possible conflict with auto-focus on checkout fields

Body:

Hi Shopify Devs,

I’ve built a Checkout UI Extension that dynamically adds/removes deposit products based on the shipping country selected during checkout. Here’s a quick rundown of what the extension does:

  • Listens for shippingAddress changes via useShippingAddress().
  • On a valid countryCode change, runs logic to:
    • Remove deposit-related products not needed for that region.
    • Add region-specific deposit products using applyCartLinesChange.

The behavior was rock-solid during development. Even now its completely intact But recently — and only intermittently — when I change the shipping country using the country dropdown, Shopify auto-focuses the Postal Code or City field, and that somehow disrupts my extension’s cart modification logic.

Again, this only happens when Zip Code field gets auto focused, Like in 2 out of 10 attempts which proves my logic was and still is okay unless the Auto-Focus on Zipe code field happens when shipping country changed.

Symptoms:

  • applyCartLinesChange() resolves successfully (verified in logs and DevTools network tab with success response).
  • But the cart does not reflect the changes (no line added/removed).
  • This only happens sometimes, and strangely, adding a delay using setTimeout (400–500ms) reduces but does not eliminate the issue. In this case the Auto-focus on Zip code maybe gets suppressed on most attempts but this isn’t a sufficient solution.
  • There are no errors from the extension code or hook invocations.

What I’ve Tried:

  • Verified applyCartLinesChange response is { status: "success" }.
  • Verified network tab on the operations and the response is status = 200 when the Auto focus thing happen.

Theories:

  • The auto-focus on postal code/city input might trigger a checkout re-render that wipes/overrides the cart state shortly after my updates.
  • Some internal debounce or batching of Shopify’s shipping updates might conflict with cart updates fired too soon.

Questions:

  1. Is this auto-focus behavior intentional or recently introduced?
  2. Is there a recommended pattern to queue or delay cart modifications safely after country updates?
  3. Are there lifecycle hooks or callbacks we can rely on to detect when the Shopify checkout has “settled” post-country-change?
  4. Can applyCartLinesChange() be “cancelled” silently if another re-render or input focus event happens soon after?

Any advice, patterns, or insights from the team or community would be incredibly helpful!
Thanks in advance!

1 Like
2

Hey @work4inventions :waving_hand: thanks for reaching out. This is the first report of this behaviour I’ve seen on my end, and does definitely seem odd. I’m wondering if it potentially has to do with race conditions on our side where one change takes precedent over the other (I have seen issues like this pop up before in Checkout UI extensions, specifically with Cart Lines.). Adding the delay does point to this being a potential reason for that happening, especially since the applyCartLinesChange call does return a successful response.

Would you be able to share an example of a full applyCartLinesChange action request/response if possible (as well as the shop ID for the affected merchant)? If you have timestamps for an example of this happening that would be super helpful as well, we can check logs on our end to narrow down if something is happening on our side of things. Also helpful would be the X-Request-ID header from the network request if you’re able to share that!

Hope to hear from you soon :slight_smile:

3

Hey @Alan_G, Thanks for the clarification. Here’s a real instance where applyCartLinesChange returned a success response, but no changes were reflected in the checkout UI. This issue occurs only when the country dropdown is changed and the checkout auto-focuses on the postal code or city field.

Request/Response (captured in logs)

Request:

{
  "type": "addCartLine",
  "merchandiseId": "gid://shopify/ProductVariant/51722962436360",
  "quantity": 6
}

Response:

{  "type": "success"}

Request IDs (200 OK responses, no UI update):

  • 28cad949-3afc-4d15-b003-ac4661950517-1751517312
  • 59df990b-662a-4cc1-a014-05de234de17a-1751517312
  • eb4c8199-5477-4c6a-bbdd-5adbed656963-1751517313
    Timestamp:
    Thu, 03 Jul 2025 04:35:13 GMT

Relevant Code Context

await applyCartLinesChange({
  type: 'addCartLine',
  merchandiseId: `gid://shopify/ProductVariant/${productId}`,
  quantity: requiredQuantity
}).then(response => {
  console.log("Response for adding line", merchandiseId, response);
});

This runs inside a setTimeout after detecting a shippingAddress.countryCode change as I mentioned that setTimeout with 500ms resolved partially but suppressed Shopify’s auto focus behaviour:

useEffect(() => {
  const { countryCode } = shippingAddress || {};
  if (countryCode && countryCode !== currentRegion) {
    const timeoutId = setTimeout(async () => {
      if (countryCode === shippingAddress?.countryCode) {
        await handleDepositProducts(countryCode);
        setCurrentRegion(countryCode);
      }
    }, 100);
    return () => clearTimeout(timeoutId);
  }
}, [shippingAddress]);

We added the timeout to mitigate this issue, and it works most of the time. But when autofocus kicks in immediately after the country change, the cart updates still sometimes fail to render in the UI despite success responses.

Shop Info

  • Shop domain: saturo-dev3.myshopify.com
  • Shop ID: 97087881480
4

Hey @Alan_G I hope to hear from you soon : )

5

Hey @work4inventions, sincere apologies for the delay in getting back to you. Thanks you for your patience on this and the details you shared.

I think my next step here is to get in touch with our product team to see if this is a possible issue on our end, but there’s one last check/confirmation that would be incredibly helpful.

Just want to clarify, when the UI doesn’t update after a successful applyCartLinesChange call, could you verify if useCartLines() actually shows the correct updated cart state or if you can check to see if the cart itself is updated in the storefront cart page if possible? This would help us determine if it’s purely a UI rendering issue versus the cart state itself not updating properly.

Once I have this final piece, I think I’ll have everything needed to get this properly investigated by our Checkout UI team.

Thanks again for bearing with me on this, I really appreciate you pinging me in the thread here again, we’ll get this looked at.

6

Sure, I’d get back to you with that clarification. Thank you for your response and attention on this issue.

7

Hey @Alan_G , I verified state sourced from useCartLines() does not get updated.
Here is how I checked it out,

  1. Directly after applyCartLinesChange call.
  2. 500ms delay after applyCartLinesChange call.
  3. Log the state on checkout load to check fresh state of useCartLines() , By refreshing after the operations (non-updated UI case). It doesn’t contain the added lines.

For more context:

And another thing I observed is something into the logs which might be related to this issue. (Though, didn’t go deep into this to know the root of occurrences but I assume it’s when there is a setTimeOut which suppresses auto-focus on shipping country change )

Here it is,

Let me know if you’d like me to dig into any other details, Thanks again!!!

8

Hey @work4inventions, thanks for confirming that useCartLines() doesn’t reflect the updated state - this does seem to be a cart state issue, not just UI rendering.

The auto-focus behavior and applyCartLinesChange failing silently despite success responses is definitely a bit concerning.

If you have any additional Request IDs and timestamps from other occurrences beyond the three you’ve already shared (you should be able to find the request IDs in the API response headers for those actions in Chrome Dev tools), those would be helpful. Also, if you’re able to, capture the full error logs around that “Cannot set properties of null” error (no worries if not), that would give us more context. As well, if possible, a screen recording showing the exact replication steps and the auto-focus behavior when it fails would be incredibly valuable for our team to understand the issue so we can replicate things on our end here.

Once I have this, my next step will be reaching out to the relevant product team on our end with all the details.

In the meantime, I’d definitely say to continue with your 500ms setTimeout workaround. You might also want to consider adding a verification check after applyCartLinesChange to retry if useCartLines() doesn’t update within a reasonable timeframe at your code-level for the time being.

Hope to hear from you soon so we can get this properly looked at!

9

Hi @Alan_G,

Following up with the details you requested.

Video Explanation
The video linked below demonstrates the specific instances where the issue occurs.
To make the issue easier to reproduce, I temporarily reduced the TimeOut value from 500 to 100.

Watch the video

Logic Overview

Here’s a breakdown of the current logic implemented:

  • When Austria is selected:

    • Removes any deposit lines related to Germany (if present)
    • Adds deposit lines for Austria

  • When Germany is selected:

    • Removes any deposit lines related to Austria (if present)
    • Adds deposit lines for Germany

  • When any other country is selected:

    • Removes all existing deposit lines, regardless of country

Failed Request IDs with Timestamps

  • 219f9a02-dad2-4dc5-b642-bb03a5d04847 – Fri, 18 Jul 2025 07:03:59 GMT
  • 41d83534-de09-4a34-a581-63bc09988c79 – Fri, 18 Jul 2025 07:03:58 GMT
  • f196d6c7-cdd5-4859-ad38-628c745c249f – Fri, 18 Jul 2025 07:04:00 GMT
  • c4919aad-1893-4bb8-92a8-d4056709b927 – Fri, 18 Jul 2025 07:07:46 GMT
  • 9da78b80-60d8-4dc9-9a84-7ee194929784 – Fri, 18 Jul 2025 07:08:27 GMT
  • ebab3d4a-02f9-4336-ba3d-7fed29581b86 – Fri, 18 Jul 2025 07:08:27 GMT
  • 1358b8d5-eaca-4076-a1e0-4fcc931741eb – Fri, 18 Jul 2025 07:08:28 GMT

Please let me know if further information is needed or if you’d like me to run additional tests.

10

Hi @work4inventions - thanks very much for all the info, it’s really appreciated. I’ve reached out to the team on my end and I’ll keep you up to date on this here in the thread. Speak with you as soon as I have more to share/if I can confirm a fix.

1 Like
12

Hey @work4inventions, thanks again for your patience and all the details you shared on this.

I just wanted to loop back with you here, since I was able to touch base with our Checkout UI team.

We took a closer look at the logs from those request IDs and timestamps, and from what we can tell, it turns out the issue stems from a timing condition where changing the shipping country will refresh cart line IDs in the background, leading to “stale” IDs being used in your applyCartLinesChange calls. This causes silent failures (like the “Unknown line item id” errors we saw in logs), even if the initial response appears successful. The auto-focus on postal code/city seems to coincide but isn’t the root cause, it’s more about these concurrent updates, but this behaviour is expected since on our end, we are returning API responses for these changes from what we can see on our end.

Our product team recommended always checking the full API response from applyCartLinesChange (beyond just the top-level { type: "success" }) and implementing retries if it indicates an error, such as the invalid line ID there.

You may also want to subscribe to cart line changes (e.g., via useCartLines()) alongside shipping address updates in your useEffect dependencies. This way, if the initial change fails due to stale IDs, your logic can re-trigger once the lines refresh. Pairing this with your existing setTimeout (100-500ms) should resolve the intermittency reliably.

Let me know how this goes, if you share any updated logs or responses and the issue still seems to be happening, just let me know here and we can take another look. Appreciate you working through this with us and for your patience on this! :slight_smile:

13

Hey @Alan_G , Thanks for the detailed explanation.
The line item operation response gives { type: "success" } and that’s pretty much it. I didn’t see anything else though.

I’d try the suggested changes at my side and let you know how it turned out.

Again, Thanks for the attention on the issue. I’d come with an update on this solution soon.

14

Hey @Alan_G , I observed the post marked as solution,

Just to note, Again, thanks for the follow-up and for checking with the Checkout UI team.

However, I’m unmarking this as the solution because while the explanation helps clarify the cause, it doesn’t resolve the underlying platform issue. What you’ve provided is a workaround that I, as an app developer, now need to implement to mitigate behavior that stems from how Shopify internally refreshes cart line IDs during country/address changes.

From my side, I’m following the Checkout UI Extension conventions correctly using applyCartLinesChange, tracking state with useCartLines(), and reacting as per your recommended practices. The API returning { type: "success" } while silently failing due to stale IDs have been misleading until now, and ideally, this should be handled or at least more clearly documented within the platform. Even if it shows me an error, Eventually I did everything exactly how documented.

To be more precise,
I’m using useApplyCartLinesChange() exactly as documented, and it’s expected to handle cart line updates reliably within the extension lifecycle. If the platform abstracts a utility hook and stongly claims it performs an action (like adding/removing lines), then it should just do that unless I’m using it incorrectly in a syntactic or logical way. However, in this case, the failure is due to internal ID invalidation that’s not documented, not surfaced in the response properly until now (as an additional error), and not expected to be handled by the developer unless they’ve reverse-engineered the behavior.

I understand the complexity behind concurrent updates, but this timing issue and ID invalidation feel like something the platform should abstract away or provide more robust tools to deal with rather than pushing all the retry/revalidation logic onto developers.

While I really appreciate your help so far and will implement the suggested thing but it is just a safeguard, just wanted to clarify why I don’t consider this a final solution. This is not the Ideal & quality development practice to be handled by Checkout UI Extension Developers. So I still expect an official fix from platform and remove the piece of code from my side which shouldn’t be on an ideal CUI extension specially if Documentation claims to use abstracted methods to perform something.

15

Hey @work4inventions, I hear you on this, and I really appreciate you taking the time to share your feedback here .

It’s for sure frustrating when the functionality doesn’t work as smoothly as expected, especially if it’s implied in the documentation. I can definitely see why this feels like something the platform should handle more gracefully.

I’m going to share your feedback with our developers because you’re right that this creates extra work for extension developers. These kinds of timing issues in distributed systems are tricky, but your point about better abstractions is fair.

I’m going to log some official feedback with reference to this thread and your specific points when I escalate this as well.

Let me know if you’d like help with the workaround in the short term, and I’ll keep you posted on any updates here from the team about longer-term improvements ( I can’t guarantee anything on my end, but just ping me here and I’d be happy to take a look at anytime) :slight_smile: