Make "retry" logic more extensible about volley HOT 3 CLOSED

In general, I'd prefer to avoid a patch to BasicNetwork that attempts retries in new situations by default. However, it's fine with me if the change is reasonable and gated by something that is opt-in.

For example, you can see:

dd439dc

where we added Request#setShouldRetryServerErrors. If true, 5xx errors will be passed to the RetryPolicy as you describe. But it's not true by default, so the prior behavior is retained if you take no action.

So the above change should actually take care of retrying most instances of ServerError. The only exception I see is a 3xx "error" which is actually a redirect request, so it's not clear to me why you'd want to retry these. So does setShouldRetryServerErrors take care of your needs?

NetworkError should already be hitting any RetryPolicy implementation that is attached to the request:

https://github.com/google/volley/blob/master/src/main/java/com/android/volley/toolbox/BasicNetwork.java#L177

So AFAIK, the only possible delta you'd be asking for here would be retrying on 3xx errors... if there's a valid reason to do that, I'm willing to hear it, but it seems a bit peculiar to me.

from volley.

Thanks. I agree that it doesn't make sense to retry on 3xx errors. Actually, it's the NoConnectionError errors I was hoping to retry on, not the ServerErrors:

https://github.com/google/volley/blob/master/src/main/java/com/android/volley/toolbox/BasicNetwork.java#L151

We have an app that gathers a bunch of data on the UI from users who tend to wander around a building in which there's spotty Wi-Fi connectivity. We'd like to fire off requests to Volley safe in the knowledge that if we're not actually connected to the internet right now, we'll get a retry later on. I'd imagine that the same need would apply to consumer apps using mobile data.

Would a setShouldRetryNoConnectionErrors() flag, defaulting to off, be generally useful?

from volley.

Sorry, I realise now that the backoff implemented with the retry policy in Volley is about timeouts, not resending a request after some delay. You're waiting successively longer for a response, but you're not resending a request after some delay. It's the resend after a delay I was looking for, so I've implemented that without extending anything in Volley. Closing this.

from volley.