Hi @Alan_G, would you be able to have a look into this one for me please?
I’ve also gotten this response back from Shopify via another merchant.
Bespoke Shipping was right that these aren’t timeout errors. What’s actually happening is that Bespoke’s system takes 4-5 seconds to calculate rates, and when your customers update their cart during that window (very common behavior - applying discounts, changing quantities, refreshing), our platform drops the duplicate request to protect the checkout experience and shows backup rates instead. This is working as designed on our side - we’re protecting your customers from waiting indefinitely and making sure they can complete checkout smoothly.
What is alarming about this response is:
- This behaviour is not documented
- If the cart changes, then Shopify should refresh rates as there is a genuine need for new rates, throwing incorrect rates instead is absurd - this is akin to clicking a link on your browser and if the page takes too long to load, the user clicks on another link, and instead of serving you the page you clicked on, it severs you a random page to ‘keep you engaged’
- This is really also reframing the timeout to the timing of the first interaction which can be much lower than 10s, if so what is the point of the published timeouts?
So for this merchant, they are sourcing live rates and their carrier simply takes that long to calculate a rate as they are sourcing it from multiple sources. There isn’t anything we can do here to speed up the issue.
To clarify for the test we ran on our dev store:
- The HTTP_X_SHOPIFY_TIMEOUT header is 10s on this payload
- there is no iteraction to the checkout after entering the address and waiting for rates to load
- backup rates thrown at 5s not 10s
@NickLozon @Joel_Reeds you guys may be interested in this too.