Adjust infinitely retries requests that fail

[dlew]

I was looking into devices that purposefully block Adjust's requests (e.g., devices on a pi-hole network) and discovered that Adjust does not have a maximum number of retries for any given request. It looks like it'll just keep retrying infinitely, which isn't great.

I would add my own max retry logic (and disable Adjust if it looks like it'll simply never work) but due to #355 there's no way to tell if sdk_click is failing, and that's the event that a device gets stuck on when it's on an ad-blocking network.

[uerceg]

The most important purpose of our SDK is to deliver certain information to our backend successfully and in order of happening. It is of vital interest for any data displayed in our dashboard that packages that are part of our main package queue (session, event and sdk_info) are processed and delivered to our backend in order they actually happened.

It is true that SDK doesn't have a mechanism which will give up on sending these packages after certain time and simply drop them. And it will probably never have it, since dropping them means that we dropped some important information app wanted us to track.

Upon each failed attempt to send certain package, SDK will not just continue spamming with network requests endlessly w/o any sense. When ever request fails, SDK is invoking exponential backoff strategy to determine time when next try is gonna happen. So it can go something like 1min, 6min, 15min, etc, etc, up to max 24 hours.

On SDK side, we will probably not build any logic that will try to understand if certain packages should be dropped after a while or not. This is something we have in mind as some potential new features, but if we go with the implementation, it will be something which will be instructed to SDK from backend side (not to retry it anymore or just drop the package). But this assumes that SDK manages to ping backend with request that fails for some reason. If SDK doesn't manage to send anything due to for example lack of internet connection, I don't think that that we will go with any package dropping on our own, since what ever our SDK is trying to send is actually information that we want our backend to be aware of because lots of things depends on it. We might change the way how we retry (frequency), but the fact that we will always retry, we probably won't.

Regarding comment on your retry logic, I see how that would suit you. Comment on that I wrote on that issue.

[dlew]

When ever request fails, SDK is invoking exponential backoff strategy to determine time when next try is gonna happen. So it can go something like 1min, 6min, 15min, etc, etc, up to max 24 hours.

That's true, but what worries me is that the SDK does not persist retry count. So if you've already retried 20 times, it'll wait a long time before trying again, UNLESS the app is killed and restarted in the background, at which point it retries a bunch of times again immediately.

If SDK doesn't manage to send anything due to for example lack of internet connection, I don't think that that we will go with any package dropping on our own, since what ever our SDK is trying to send is actually information that we want our backend to be aware of because lots of things depends on it.

I'm not talking about a lack of internet connection - I'm talking about something that is purposefully blocking the Adjust SDK in particular (e.g., rerouting your DNS queries to localhost). But I get that this is a fairly rare circumstance.

[dlew]

Also, from my own testing, every time Adjust.onResume() is called it attempts to make new network calls, even if it's already waiting on backoff due to a previously failed request. So while sdk_click may be waiting 24 hours, the user navigating around the app will keep trying to send network requests.