Complete

WERETECH-7625

Future 3.1.1 Release

Started getting a lot of BLE_REQUEST_TOO_LARGE - outgoing makeWebRequest doesn't even pass to server

Hello, recently (after some firmware or Connect app update?) I started getting BLE_REQUEST_TOO_LARGE (code -102) as a response to my makeWebRequest (it's a request from watchface's background service). 

The server doesn't even register this request, which means that it doesn't pass from watch. However, the url (https) is now only about 160 characters, and it has worked without problems for about a year.

Is there anything I can do to even debug this? Is there a known bug (Vivoactive 3) about this?

I tried shortening the request url as much as possible (it is now about 140 bytes), but no improvement, and much longer urls worked for me in the past.

  • on a va3, the background has a max of 32k (well, really 28k as the vm takes some).  How large is the response?  Is it complex?

  • This is happening on VA3 where it is quite comfortable - before Background.exit() I have cca 25 kB used, 100 kB free (according to Sys.getSystemStats()). And in main thread there is also enough RAM (78 kB used, 16 kB free at about the most intensive point during drawing).

    (The RAM is much tighter on VAHR, but this is happening on my VA3 right now).

    I had BLE_REQUEST_TOO_LARGE before, and managed to make at appear less by shortening the url, but now when it's down to about 140 chars it's ridiculous. And the problem seems to be with sending, as the request doesn't even reach server (I watch the log while testing the watchface).

    I thought if this is really a problem with BLE stack, so I restarted both iPhone and VA3, but no help. 

    Any idea? For me, CIQ on VA3 now seems broken, and it seems to have started with one of recent updates.

  • How tight on memory are you in the background process and the watch face itself?

  • Oh, and as always, the same request works perfectly from simulator.

    (Background.exit() has same problems - it passes in simulator, but the same data (about 1 kB JSON) throws ExitDataSizeLimitException on a real watch, despite the promise of it passing up to 8 kB in docs).