Solved

Configure timeout for HTTPClient

  • 8 March 2022
  • 7 replies
  • 217 views
D
Badge +1

Hey there, I have looked online and in the forums but could not find a way to configure the HTTPClient with customable timeout.

Basically from my code overview (iOS SDK - https://github.com/RevenueCat/purchases-ios) the HTTPClient is internal to the SDK and you cannot configure it - am I wrong?

We suffered from long timeout today which caused our application to hang.

It could be a nice addition to the Purchases singleton API to add additional configuration for different underlying services the default o60 seconds of NSURLSession is obsolete.

I also encoutered this PR - https://github.com/RevenueCat/purchases-ios/pull/910 that enabled timeout for SKProductRequest - again allowing to configure it from outside of the SDK could be handy.

icon

Best answer by Andy 18 March 2022, 19:52

View original

7 replies

Andy
Rank
Userlevel 5
Badge +8

Hey @danibachar, 

We don’t currently expose the timeout as a configurable parameter, the SDK relies on iOS defaults. 

Timeouts are tricky to get right because tolerance can vary quite a bit depending on the available connectivity for different places. 

As you pointed out, there’s only a single place where our SDK actually sets a custom value for timeouts, and that’s exclusively used for requests to fetch products from StoreKit. 

The reason for that is that SKProductsRequest, which a part of iOS and is what the SDK uses, doesn’t actually provide a way to set a timeout, and in some buggy versions of iOS it can hang potentially forever. 

So we added a timeout so apps wouldn’t hang when there’s an iOS bug. 

I’m not opposed to the idea of making it configurable, though. Could you tell me more about your  particular case?

Were you able to track the actual network request that was timing out? Our API usually responds in milliseconds, but calls to Apple’s StoreKit take a lot longer sadly. 

I’m asking because the implementation of it could vary widely depending on where the timeout would be needed. 

 

If you haven’t tracked the actual network request that was timing out, do you know which method your app was calling in the SDK? 

Andy
D
Badge +1

Thanks for your response Andy!

 

A few weeks ago RevenueCat suffered from a short outage, I think it was on March 7th 12:00-12:05 UTC.

Several of our users suffered degraded performance by RevenewCat at this time and we even managed to track the issue live.

Our app had a design flaw, where we would have used the `Purchase` SDK login functionality the

(void)  logIn:(NSString *)appUserID completionBlock:(void (^)(RCPurchaserInfo * _Nullable purchaserInfo, BOOL created, NSError *_Nullable error))completion

every time on the splash screen - i.e when loading the app. While you actually need to do so only once (kind of correlated to the application login). So at the outage, users opened the app and hang due to this call - not even one have waited the 60s default timeout, which would have arrived eventually and allow the initialization of the application to continue (we tested it and made sure this was the problem and managed to reproduce it).

 

We fixed this design issue, nevertheless our product requires much shorter timeouts to any kind of communication - especially time critical like login and fetching the user purchase history (which our application depends on in a very coupled way).

 

Eventually, I ended up introducing a simple timeout mechanism to the wrapper service that we use above the `Purchase` SDK.

 

It could be a nice to have configuration to the underlying NSURLSession you guys are using, and to take advantage of the native timeout mechanism instead of implementing it by ourselves.

Andy
Rank
Userlevel 5
Badge +8

@danibachar that makes sense, and it’s very valid feedback. Thanks for the context!

 

We have a few things planned out to make the SDK more resilient to backend outages, but I think what you suggest still makes sense, since there are situations where the SDK will still be susceptible to backend outages.

 

I have added an item for a public-facing timeout to the backlog, but I don’t have an ETA for it yet. 

 

Thanks again for your suggestion! I look forward to implementing it! 

Andy
D
Badge +1

No worries at all, and thanks again for the responsiveness.

We love RevenueCat - it really helped us scale and build our application fast!

We are in the process of enriching our wrapper service above RevenueCat with caching and some other functionalities we specifically need in our app.

The timeout feature seemed like something that could be useful to others - are you guys open for contribution to the public SDK?

Andy
Rank
Userlevel 5
Badge +8

We love RevenueCat - it really helped us scale and build our application fast!

This made my day ❤️

 

The timeout feature seemed like something that could be useful to others - are you guys open for contribution to the public SDK?

 

We absolutely are! Feel free to open up a PR (even a WIP draft) and we can move the discussion there 😃 I’m aboedo in GitHub if you’d like to tag me on the PR

Andy
A

Hey @danibachar, we just merged https://github.com/RevenueCat/purchases-ios/pull/1556 Which creates a new configure API that takes in a configuration object where you can set some timeout values.


let configuration = Configuration.Builder(withAPIKey: "MyKey")
                                 .with(networkTimeout: 15)
                                 .with(storeKit1Timeout: 15)
                                 .build()
Purchases.configure(with: configuration)

It will be in our next release (not currently planned, but should be in the next few weeks). 

D
Badge +1

Thank yoo guys for taking care of it. Great addition!

Reply


Terms & ConditionsCookie settings