Page MenuHomePhabricator

[native] Verify if the backup version is correct
ClosedPublic

Authored by tomek on May 13 2024, 3:30 AM.
Tags
None
Referenced Files
Unknown Object (File)
Wed, Nov 13, 9:28 PM
Unknown Object (File)
Tue, Nov 12, 9:49 PM
Unknown Object (File)
Tue, Nov 12, 9:22 PM
Unknown Object (File)
Sun, Nov 3, 10:36 AM
Unknown Object (File)
Oct 14 2024, 5:21 PM
Unknown Object (File)
Oct 12 2024, 6:20 PM
Unknown Object (File)
Oct 12 2024, 6:20 PM
Unknown Object (File)
Oct 12 2024, 6:20 PM
Subscribers

Details

Summary
Test Plan

Checked if restoration of the backup fails when a version of the backup is newer than the app.

Diff Detail

Repository
rCOMM Comm
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

tomek requested review of this revision.May 13 2024, 3:45 AM
kamil added inline comments.
native/backup/use-client-backup.js
93–96 ↗(On Diff #40108)

would love to see this using sqliteAPI and being wrapped in a utils function from /lib like verifyBackupVersion() to have a symmetric condition on both platforms but guess it's not that easy - mostly because in D11947 on web part this is done by the worker

97 ↗(On Diff #40108)

There is a difference between web and native about calling setPersistStorageItem - to unify that we first need ENG-3504

This revision is now accepted and ready to land.May 14 2024, 11:35 PM
native/backup/use-client-backup.js
93–96 ↗(On Diff #40108)

This code will probably change as a result of a discussion from https://linear.app/comm/issue/ENG-7008/detect-that-the-compaction-is-from-a-newer-version-than-the-app-and#comment-2712fb37. But overall, I agree that making the code more symmetric is beneficial. On the other hand, this could get expensive.

native/backup/use-client-backup.js
93 ↗(On Diff #40227)

This approach is confusing to me. It looks like we need to let restoration happen to be able to learn whether we should have performed restore at all.

If we want to proceed this way we need to delete database in this case.

In the comment you mention that this will change due to discussion on Linear and you are going to modify rust to take expected database version. Is this modification going to include database deletion if there is a version mismatch? We can't let the app remain in a state where database is corrupted.

Check the version before restoring

tomek requested review of this revision.May 17 2024, 2:09 PM
tomek added inline comments.
native/backup/use-client-backup.js
93 ↗(On Diff #40227)

I changed the approach - now we're checking the version before restoring.

tomek edited the test plan for this revision. (Show Details)
kamil added 1 blocking reviewer(s): marcin.
kamil added inline comments.
native/cpp/CommonCpp/DatabaseManagers/SQLiteQueryExecutor.cpp
1855 ↗(On Diff #40346)

shouldn't we throw in this case?

marcin added inline comments.
native/cpp/CommonCpp/DatabaseManagers/SQLiteQueryExecutor.cpp
1852 ↗(On Diff #40346)

This isn't very readable. It looks that you expect entries to be exactly one element array. it would be better to just check for that and throw an error if this requirement is not satisfied.

This revision is now accepted and ready to land.May 20 2024, 3:29 AM
native/cpp/CommonCpp/DatabaseManagers/SQLiteQueryExecutor.cpp
1852 ↗(On Diff #40346)

Alternatively if your requirement is not that strict - you let entires array be either empty or one element than you can just update this code to return optional. Returning -1 is very C-style low level

Rebase and handle missing version

native/cpp/CommonCpp/DatabaseManagers/SQLiteQueryExecutor.cpp
1852 ↗(On Diff #40346)

Updated with an optional

1855 ↗(On Diff #40346)

Not sure. Maybe it is a good idea to start doing it in the future because we expect that every backup has a version.