App should handle 429 different and increase then the timeout as long as 429 happens

[nigzak]

My app did not work because I did not change the sensor and longer time was no data available (2h+) (Source app: Freestyle Libre) In the log was appearing HTTP 429 which means "too many requests" even after sensor replacement.

In case of this HTTP code 429 it would probably good to increase the poll interval to avoid getting kicked out continuously? If the application still "fires" to the API it could be that it gets not out of the 429

Like

// START OF POLL OF API
// ... all other code done of the poll, this should be as final code somewhere there for the next round
IF (HTTP_CODE = 429) 
   set SLEEP_TIME  = ORIGIN_VALUE + 5m // or any other value?
ELSE
  set SLEEP_TIME = ORIGIN_VALUE // RESET BACK

SLEEP(SLEEP_TIME) // don't exactly now how you implement it
// END OF THE POLL OF API

Hint: as fix for this I restarted my phone which also stopped the poll shortly - after restart (with short interrupted poll) it worked again. This "smells" to me that this "temporary" increase could fix this automatically (there is no button to "pause" it so only possibility seemed to me to restart phone to force a pause in the polling)

[petechap]

I'm having the same 429 errors except in my case a short time offline only let me poll a couple of times before the 429 errors returned. A configurable interval or automatic back-off would be great.

[elceef]

I noticed this issue too. After empty response (0 entries) the app starts polling remote server in 5 second intervals, despite much higher cloud latency parameter set. This inevitably leads to HTTP 429 error which isn't handled properly. As a consequence, an infinite query and response loop occurs.

Sending LibreLinkup data request... 
0 entries received at: 12:10:31
Sending LibreLinkUp data request... 
0 entries received at: 12:10:33
Sending LibreLinkUp data request... 
0 entries received at: 12:10:38
Sending LibreLinkUp data request... 
0 entries received at: 12:10:42
Sending LibreLinkUp data request...
FAILED: HTTP 429 - 
Sending LibreLinkUp auth request... 
Sending LibreLinkUp auth request... 
OK 
Sending LibreLinkUp session request...
FAILED: HTTP 429 - 
Sending LibreLinkUp auth request... 
Sending LibreLinkUp auth request...
OK 
Sending LibreLinkUp session request...
FAILED: HTTP 429 -

[trupici]

The server response status 429 was not present before the latest LL server update. However, this response is used correctly to limit too often requests from clients. The correct handling would be to make the next request after delay sent from the server in corresponding header. I will make also a hard coded limit for 1 min. Will need some help from users here since I don't have access to Libre sensors now.

[Saortica]

Happy to help

[Saortica]

I've got an annoying workaround that is probably pretty obvious, just in case you want to kick start it again - force stop the g-watch wear app, then in the time it takes to load it back up again, the 429 loop seems to be broken.

Note: it needs to be forced stopped via App info or in settings, not in the task list.

[petechap]

Will need some help from users here since I don't have access to Libre sensors now.

I guess you don't need access to libre sensors for this, just to be receiving data from librelinkup? I'm happy to share my BG readings with you (i.e. email you a LL invite) if it helps test a fix.

[trupici]

commit: 9342c4b9d3fde291630f1fe2c43fcd5d0eda3712

[nigzak]

Hi together

sorry for late response ... I am currently very busy because of I have had to search for new apartment and all stuff which comes with this ... If there is anything I can help let me know.

Thanks :)

[trupici]

fixed in version 0.9.7