react-native-background-geolocation icon indicating copy to clipboard operation
react-native-background-geolocation copied to clipboard

Ability to control http retry behaviour

Open mlev opened this issue 1 year ago • 4 comments

Your Environment

  • Plugin version: 4.16.1
  • Platform: Android
  • OS version: 14
  • Device manufacturer / model: Google Pixel 7
  • React Native version (react-native -v): 0.73.6 (Expo 50)

Expected Behavior

Can configure plugin's http retry policy

Actual Behavior

As soon as a single error occurs it doesn't try to sync until 10 more locations have been collected. Depending on other configuration settings this can be a long time.

Context

I tested at the weekend and got a little caught out by how the lib handles http errors. The mobile connectivity was patchy and when I checked the locations that had been synced they were often well out of date. Because I knew I had connectivity at that point I stopped and started the service and the locations came through as expected.

Checking the logs afterwards I can see the reason for this is that soon as one error occurs it doesn’t retry to send again until 10 locations later. I had a distanceFilter of 250m so this meant a long wait between attempts. I assume this behaviour is to preserve battery but given my configuration was to autoSync every location this wasn’t expected and isn’t documented or controllable as far as I can tell. I had already set my distance filter to a largish value to reduce locations and required http requests.

I suspect a complicating factor is that often my mobile would say it was connected, but when you tried to load anything the connection would timeout.

What would be the recommended configuration for this scenario?

  • Use a smaller distance filter and set an autoSync threshold: This would reduce the delay when this scenario occurs but also increases the location count significantly
  • Set max records to persist: As far as I can tell this will just disable the backoff entirely. Again not really expected.
  • Custom event listener: I assume there's probably some workaround possible but not sure what needs to be overridden

It would be great if you could control this retry policy - or at a minimum I feel it should be documented so that other configuration can be set according to the situation.

Thanks

mlev avatar May 20 '24 07:05 mlev

You are free to manually call .sync() to immediately retry.

christocracy avatar May 20 '24 12:05 christocracy

Ah ok - so catch the error in the http event listener and then call sync() as required. Yes that could work, thanks.

...but it would still be nice if this was more controllable in the plugin. Even just a flag to turn it off so you know what to expect. As it is any extra logic needs to work in conjunction with the current back-off logic, which isn't clearly defined.

mlev avatar May 21 '24 01:05 mlev

This issue is stale because it has been open for 30 days with no activity.

github-actions[bot] avatar Jun 20 '24 01:06 github-actions[bot]

Not a lot of traction on this but I still think the intended behaviour should be documented. i.e.

  • Once a HTTP error occurs, auto syncing won't be attempted until 10 more locations have been collected.
  • If maxRecordsToPersist is enabled then this behaviour is disabled and auto-syncing will be attempted for every location received, regardless of errors.

mlev avatar Jun 20 '24 06:06 mlev

This issue is stale because it has been open for 30 days with no activity.

github-actions[bot] avatar Jul 21 '24 01:07 github-actions[bot]

This issue was closed because it has been inactive for 14 days since being marked as stale.

github-actions[bot] avatar Aug 04 '24 01:08 github-actions[bot]