Couldn't connect to server #72
Comments
|
Maybe related to square/okhttp#3974 ? |
|
|
Well, if this is thrown when refreshing from the UI, I think it makes sense, since we are calling the This makes the worker not to include the network type |
|
Actually it's the other way around :-/ This error mostly occurs when a sync is done in the background (manually refreshing via UI works) and the network is not ready yet. So the question is why does the system have the state EDIT: Ah I think I understand what you mean now. Maybe this has an effect on this. Let's wait for @rfc2822 to look at your findings! |
|
Android is horrible checking if it has Internet connection or not, when the signal strength is low, or if the mobile network repeater reports a wrong connectivity speed (e.g. reporting LTE with E speeds) it just breaks, and doesn't know if Internet works or not. In any case, I don't think that should cause major issues, only on some specific cases, so I don't think that's the issue here. |
|
I have been thinking a bit on this. Since before adding the calendar, it's checked that it exists, we can just assume that the server is not going to be deleted. Then, in the worker: icsx5/app/src/main/java/at/bitfire/icsdroid/SyncWorker.kt Lines 68 to 80 in 508bc64 We try-catch an override suspend fun doWork(): Result {
val forceResync = inputData.getBoolean(FORCE_RESYNC, false)
var serverUnreachable = false
applicationContext.contentResolver.acquireContentProviderClient(CalendarContract.AUTHORITY)?.let { providerClient ->
try {
return withContext(Dispatchers.Default) {
performSync(AppAccount.get(applicationContext), providerClient, forceResync)
}
}catch (e: UnknownHostException) {
Log.w(Constants.TAG, "Could not reach server. Trying again later.", e)
serverUnreachable = true
} finally {
providerClient.closeCompat()
}
}
return if (serverUnreachable)
Result.retry()
else
Result.failure()
}I think |
|
I also think that we should try a defined number of times (regardless of the actual I/O exception) before reporting the error. However I wonder what's the real cause of the problem (no Internet connection although WorkManager says so) and why I can't find anything about it "on the Internet" – maybe it's only related to okhttp? |
|
Well, it's a DNS error. It can't find an IP address associated with that domain. What comes up to my mind is bad Internet connection, so that when the workmanager checks for connectivity, it's available, but a moment later, when the proper code runs, that connection is no longer available. |
We can use an extra data key for this, and keep incrementing it and returning |
|
Just found out there's a thing called |
|
I've commited a94e7ad, which adds a constant for the maximum number of attempts: icsx5/app/src/main/java/at/bitfire/icsdroid/SyncWorker.kt Lines 28 to 34 in a94e7ad And then, when the job fails, we return a failure or a retry depending on this count: icsx5/app/src/main/java/at/bitfire/icsdroid/SyncWorker.kt Lines 84 to 89 in a94e7ad However, even though this might fix the issue, we should still add some kind of backoff policy. |
The other exception is a timeout. I guess the first TCP package is sent while there's still no real connection and then it waits and times out. However I wonder why there are not many reports about that on StackOverflow etc. because almost every app I can imagine that uses WorkManager will require Internet for its work, so shouldn't this a very big topic? And I couldn't find anything about it. |
I've seen that most of the examples out there add an initial delay. Maybe adding this helps on the network finishing booting, and people don't even notice. However, Google should be aware of this, and I couldn't be able to find any related issues on their issuetracker. |
|
I'd add the retries logic, some backoff policy, and a short initial delay (maybe 10-20 seconds), and check if the issue is gone. Otherwise we can open an issue at Google, and check if they have got any more info |
|
All the suggested changes are implemented in #83 |
|
Thanks! I'd still want to know what's the cause of the problem instead of only working around it but maybe we will never know… |
Yeah... It's hard to know without further inspection of the insides of the |
|
Some findings:
|
|
Another report for this came in - but I think no additonal information can be gathered from the error details (basically the same as above): (S21 Ultra, Android 13) |
|
BTW is this still being reported @devvv4ever ? I didn't have the problem myself for a long time now… maybe Samsung has fixed it? |
|
No reports like this for quite a few months! We can re-open if necessary. |
Updating the calendars doesn't work regularly. Error message: "Couldn't connec to server."
Seems like the Internet connection is not ready yet when the work manager initiates the synchronization.
Similar to #24
The text was updated successfully, but these errors were encountered: