BLE_HOST_TIMEOUT - intermittent issue with MakeWebRequest

Hey Brandon.ConnectIQ, I noticed a -2 error problem in my app, using makeImageRequest. There was a large increase (about a fourfold increase) in -2 errors between August 21st, and August 27th, when this thread was created. It seemed to effect most devices, not just a specific set. It's worth noting that the errors seem back to normal now. 

Do you have any additional info on these elusive -2 errors? They make for very curious errors, and I'd love to know more about what causes them from the GCM standpoint.

Thanks!

in BLE_HOST_TIMEOUT HOST means BT or web server?

problem with IOS is because communication can be make on strange way. I don't know how it works because I'm Android user but I've seen it once when somebody installed my watch face and it lasted 5 minutes from clicking install to showing watch face. the same with data updating. There was no network on his phone so  maybe communication was made by 'iphone network'.

Hi. It seems to be related to iPhone. I’ve found a work around that seems to work. I go into the mobile settings and reset the all network settings. That seems to resolve the issue with Garmin connect mobile. Now I only get the error when I’m out of Bluetooth range or on the edge of the Bluetooth range. 

one thing that could be improved in CIQ is to extend the timeout for a background process. When there is a network issue, makewebrequest takes a few minutes to return with error code. When I run the request from foreground I get the error message and I can display an error message to the user. When running from background (watch face or data field) the background exits before I get the callback from makewebrequest and there is no error code that I can use to inform the user. 

A better approach could be to let makewebrequest timeout before the BG process times out. What do you think? 

That would mean extending the time a background service can run and that could impact both battery as well as other things with a background service.

I have no issue with getting the -2 in a background service with Android, and as I understand it, the -2 is generated by the Garmin device and not the phone. (it didn't hear back from the phone in time)

The way I do things in background services that to makeWebRequest calls, is in the callback, I either pass the data (a dictionary) or a non 200 error code (a Number), and in onBackgrounddData, if it sees a Number, the main app knows it's an error and can display it

Hi Jim. I also pass both the data and response code to the foreground but with the BLE-HOST-TUMEOUT error I didn’t get the call back before the background process timed out. That is a problem. Another solution could be to shorten the timeout for makewebrequest so that it always returns before the background process times out. When I run the same code in foreground I do get the callback with the -2 in the response code. 

How long does it take in the FG?  

Unfortunately I have not times it. A TCP handshake times out after 30 seconds and I assume that the makewebrequest adds a little bit of time on top of that before timing out. If the background process times out already after 30 seconds, it will likely time out before makewebrequest callback returns with a proper error code. If the background process timeout could be extended a little bit, we would be able to capture and display proper error messages to the users in case there is a network issue. That would be a good coding practice. 

Hi Brandon.ConnectIQ, I am not the original poster, but I am getting a similar error with my app. It works well paired to a  GCM on an android phone, but often gives a -104 error when I use makeWebRequest while paired to an iOS device. If I open GCM on the iOS device, then it stops giving a -104 error. This seems to be true for a few difference phones, iPads, and Fenix and Forerunner watches.