Changes to CarrierService API rate request timeouts - 10s -> 5s

Solved
Highlighted
Shopify Partner
12 0 5

@bligneri You said:

"A better version of carrier service is coming but not before BFCM."

Can you please provide more information on this? I haven't heard anything about this. Ideally this better version would include Discounts. 

Please loop us all in.

Thanks

0 Likes
Highlighted
Shopify Partner
12 0 5

I'll also throw in my 2 cents. This seems heavy-handed. There are stores shipping large/heavy items internationally. Getting the correct rate is critical and could make/break profitability on an order. Like everybody else has mentioned: This isn’t really within the control of many app developers… if you’re waiting for responses from 3rd party shipping carriers that take 11seconds (especially with the BFCM traffic load) then you can’t really send anything back.

Fallback rates are not a good answer IMO even if this was announced way ahead of time.

BUT if you're 100% decided on having this 5second limit my recommendation is that Shopify scramble and get a "retry" button in this error message and change it to inform the customer that there was a problem getting the shipping rates in time:

4_DCc9zf.png

^ I think that's the error customers are going to be seeing.

 

2 Likes
Highlighted
Excursionist
16 0 6

@bligneri @Alex_B Is there any chance this change at least be delayed 1 week so we can have more than a weekend to implement workarounds? October 7th would be a much better date in my opinion both for merchants and developers.

We use and promote Shopify because it just works and easy to use. Part of that is not breaking things last minute. You keep saying BFCM but that is still well enough off to surely be able to give us a little more time than the original 4 days proposed.

 

Also are merchants even aware of this change? I haven't received anything on the Shopify blog email list which actual merchants read. A post educating merchants about fallback rates and the failure modes of Shopify shipping would surely be worthwhile before BFCM. I really worry for the developers which aren't on top of the forums as they will totally be left in the dust. This is worthy of an alert banner in the Shopify admin panel for anyone who had rates over 5s in the past month.

 

Also @Bengk sadly a retry button and the existing auto retry seldom work since the time is mostly being spent on the 3rd party carrier api. They tend to have outages and slow downs for periods of time not so much randomly on a per request basis. Any upgrade to the Shopify shipping/CarrierService system surely is a help though.

FreightChick - Automate your Logistics
CartJumper - Sync with NetSuite
0 Likes
Highlighted
New Member
1 0 1

The lack of communication about this change and the haste to implement it are disappointing. The justification and proposed "fallback" approach are both weak. The recommendations to "check metrics" and "warn merchants" (by Wednesday) are not helpful. It's hard to understand how this change "was motivated by the greater good: platform performance and reliability." Many of us have weathered many BFCMs.

Saying "We have no visibility or a real understanding of why a carrier service request is slow on our end" is disingenuous when most carrier services are dependent on third-party rating APIs like UPS and FedEx. What is Shopify's plan when the UPS API is slow? Maybe Shopify could share its workaround. A year ago, shipping app developers had a pow-wow at Shopify HQ. I don't recall halving the carrier service timeout emerging as a winning idea. At a MINIMUM I'd have expected some some discussion, followed by sufficient lead time to adapt.

1 Like
Highlighted
Shopify Partner
66 1 33

Actually a retry or some sort of auto retry mechanism will work well for a large majority of my merchants, we can potentially cache all the CCS requests on our end, and by the time the first request times out and the user refreshes (or some sort of auto refresh mechanism in place) should result in a rate. This will mean Shopify doesn't need to wait around that long on the initial request and customers won't see any functional difference other than waiting a bit longer for their rates - which is what merchants deem acceptable anyway - if they didn't they wouldn't have proposed such complex rates in the first place.

0 Likes
Highlighted
Excursionist
16 0 6

Overall that just makes the response to the user slower and the load on Shopify servers higher. It also requires a bunch of extra work on the developer end and there still isn’t even a basic checkout Id to tie these retries together easily. I agree that it’s the workaround we will both probably have to implement because Shopify won’t budge even if it’s for their own good performance wise. I was contemplating it for the 10s timeout but it’s much more of a requirement for accurate rating now. Overall this situation is very sad.

 

Would be nice if Shopify said hey start a rate request and post back to this url when you have a result. Now you can have an extremely short timeout and the waiting for requests would just be cached somewhere. I admit it’s work for them to implement this but they must have to do something eventually if open connections are such a burden. Either this or some other design overhaul.

FreightChick - Automate your Logistics
CartJumper - Sync with NetSuite
1 Like
Highlighted
Shopify Partner
66 1 33

I think anything Shopify will try to do here will increase the load on their servers.

- what happens when a customer sees no rates? they will refresh incessantly until they do, instead of waiting 10s for rates to return, they will likely receive 2-3 requests each waiting 5s at the very least. a controlled retry may be better here.

- a lot of my merchants have rates calculated by supplier, the only real alternative here is to integrate this into Shopify profiles (even though currently this isn't really fit for purpose as the blending modes don't really work, nor can they apply additional logic), lets say we encourage merchants to move back here, instead of calling one app and waiting 10s, they will likely need to call many - this will increase load too.

- whilst a whitelist of merchants where the reduction in timeout is an acceptable workaround, i fear this probably wouldn't be plausible either, as every app dev will nominate all their merchants, which means they are better off not reducing the timeout at all. For the requests that doesn't take 5s or longer to return, then setting a timeout of 10s or 5s won't matter anyway as the request will return quickly.

- having an async method may work, however for really quick requests this will result in a longer overall response time too, as now there has to be some sort of request tracking going on behind the scenes, more overhead as well. This will just increase server load on both Shopify and app end too.

2 Likes
Highlighted
New Member
2 0 2

Fortunately World Options have already implemented a variable cut off to speed up our responses, it took a number of weeks. This does simply mean we don’t show the late responders at checkout, the shorter the time the fewer the carriers that respond in time. We actually monitor our carrier API response times and have done since we regularly came up with the problem with no shipping options for larger carts. If you wish to review these please just let me know.

I actually favour the change, I think when carriers see a drastic drop in shipments next week they may look at improving their response times!

However I would say that a longer response time is needed for more items in the cart. Right now we have three customers that have to process large orders manually because we simply can’t get a response back in time.

A good solution would be to offer different rate cut off times dependant upon the number of items in the cart

E.g 1-3 items = 5 seconds

4-6 items = 7.5 seconds

10+ items = 15 seconds

The likelihood of 10 items in the cart is low but a cart value we’d all benefit from, ultimately not losing the sale.

We are U.K. based so there are lots of exports, prices vary massively hence the need for calculated rates to get close to the actual shipping price. Adding these accurate prices are simply impossible in Shopify.

This number of items in a cart method will help push developers to improve, Shopify will speed up majority of orders, but this method keeps merchants who have a successful large order to display prices. If a merchant was to display a flat rate for a large order all profit would go to shipping. This method would retain Shopify merchants, improve Shopify’s carrier systems and ultimately reducing server costs and load. Shopify gets paid on the sale, the merchants get their orders, the customer gets realistic shipping prices and we all aren’t impacted at a time when we are about to enter the biggest online Black Friday and Christmas the World has ever experienced.

Lance Grew

IT Director

World Options

 

1 Like
Highlighted
Shopify Partner
46 0 9

This means I've got to split my backend calls into two seperate part; fast and slow. For example flight-related queries will probably not work any more, for express delivery.

This is going to negatively affect some stores, thus also its customers. 

The deadline is clearly unprofessionally short guys.

0 Likes
Highlighted
New Member
1 0 0

Please reconsider this decision, you’re hurting your small customers. Customers like me, from Latin America, don’t have options to set carriers and we have to create everything from scratch using the CarrierService API.

You’re going against your principles of making ecommerce reachable for anyone.

0 Likes