-
Notifications
You must be signed in to change notification settings - Fork 665
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Never ever abort sync runs / check that the connection is indeed broken before aborting on a timeout #5859
Comments
WIP Sync aborted - on server/network error
Sync aborted - on client/protocol error
Related Fixes
|
Incomplete list of potential sync run aborts during propagation stage, by looking at
|
I believe the current behavior is the correct one: We only abort the sync run if we experience fatal error (network down, server on maintainnence, ...) @michaelstingl Do you have any concrete example of error that causes the sync to abort while it should not? |
Wenn a user has some shares and/or has some external storages and/or federated shares and/or some inconsistency in the oc_filecache because the database has a problem (in some cases is normally fixed with IMO, the expected behavior, the sync-client should mark those files, and try to upload the new files (because those files are probably needed for someone else) and at the end send a summary the main errors. Like: |
The problem is that "Connection timeout" is also the error we get when the network is down. |
The client get the error that is delivered from the |
@SamuAlfageme Should we add #4622 (comment) to this meta-issue?
|
@SamuAlfageme |
@guruz my initial focus wasn't about client side problems like flaky wifi, more about error states on the server side that abort the sync run every time at the same position, so that later files will never be synced (like in @cdamken 's example) At ownCloud Conference 2017 a user even proposed to randomize the order to get a bigger chance that later files get synced, but I of course, I would prefer to fix the root cause of the problem. |
Those are not sync aborts but crashes. Will look into them to see what introduced 'em. |
Pain is the same: Later files will never get synced. oC desktop sync client need better strategies to deal with oC server or infrastructure fuckup. |
This is something for @mrow4a ;-) SCNR
But if the local storage or the network connection go away then there is only so much you can do.. :-) In general we all agree with the goal of making the discovery less costly and therefore earlier going to sync. 2.4 should already be better in this. |
@guruz In the cases above it's not about local storage and network connection. It's about mounted storages that the oC server can't access temporarily or permanently. My expectation is, that oC client continues sync with the next available file/folder. And it seems we have enough cases where this isn't the case. |
The solution is what i write in When a propagator jobs end in a connection timeout, we assume it is because the network is down and we abort the sync. But before aborting the sync, we should do a connection validator to check if the network is down or if it is a problem with that file. |
@ogoffar while it make sense for single file, when whole folder gets unavailable it is a signal that sth is wrong with the server. It could mean it is flaky network drive (user should manually remove it in server UI and client should halt for that period not to allow moving files across folders and materialize the state on faulty server) or federated share (which might lead to even worse because multiple users do changes and patent node of folder is down or faulty). What do you think ? |
Looks like another one: #6435 |
|
Another candidate: #6826 |
Only do it when it is actually a maintenance mode Issues #5088, #5859, https://github.com/owncloud/enterprise/issues/2637
Only do it when it is actually a maintenance mode Issues #5088, #5859, https://github.com/owncloud/enterprise/issues/2637
Only do it when it is actually a maintenance mode Issues #5088, #5859, https://github.com/owncloud/enterprise/issues/2637
@ogoffart @michaelstingl what exactly is ready to test here? Only abortion on error 503? |
Right, when the server returns an error 503 for a file, (but the server is not in maintainence mode) it should still sync all other files. Maybe we can just close this issue. |
Closing this aggregating issue. All individual issues will be/were tested separately. 503 error will be tested in #5088 |
👍 😍 |
Some server side errors cause the client to abort the current sync run. If the ownCloud admin or user is not able to fix the error, EVERY sync run will abort at the same position, and following files that don't have an error will NEVER sync because of this.
@SamuAlfageme We discussed this a time ago. Please link existing issues here or open new ones that could could cause this behaviour. Please also elaborate on the server improvements.
The text was updated successfully, but these errors were encountered: