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
Handle errors of database transactions #4632
Comments
Also make sure the asserts are real problems, not a problem in debug mode for 5 developers. |
After some more debugging we found out the root cause: The user is syncing to a removable disk. Later the user hibernates the machine and removes the removable disk. When he starts the computer again, the disk is still not connected, he does it seconds later once the machine is up and running again. If the sync is running when the machine is hibernated, especially the database file is open. If it wakes up from hibernation but the external disk is not yet connected, the database file is lost for the sync process, and that is why sql commands fails. In that case the client needs to bail out with an error and restart the sync. |
Hi Hi: TEST1Steps Executed
Results An error related to the db fail is shown. USB gets corrupted during the process so we need to review and repair it with a tool included at W10. After that just Unpause Sync and a sync starts without problem. At snapshot attached appears the pause sync icon due to we tried to pause sync before hibernate but it does not work in this way, sync is atomic and in case we try to pause during sync it continues. ##TEST2 Steps Executed
Results There were no error related to DB, just an error that informs about there is no Shared Folder mounted. It seems that detects there is no USB mounted and shows just that error. After that and plug in again the USB it began to work. @dragotin could we consider these results as valid ? |
@msrex your input is appreciated too, are the results ok? |
I think these tests are fine. The important bits are:
|
great, @mcastroSG time for us to close this? |
sure 😄 |
Expected behaviour
It can happen that even if the sync journal was opened successfully, that subsequent interactions fail. For that we need to check the return value of low level SyncJournal methods like
setFileRecord
and others.If for example
setFileRecord
fails, we need to bail out with a critical error.Actual behaviour
The return values are widely not checked because we assumed that if the db was opened successfully all is good.
Version where we found that: 2.1.1 and 2.2.0pre
The text was updated successfully, but these errors were encountered: