Page MenuHomePhabricator

[web] Restore compaction
ClosedPublic

Authored by michal on Feb 12 2024, 7:27 AM.
Tags
None
Referenced Files
Unknown Object (File)
Wed, Nov 6, 5:34 PM
Unknown Object (File)
Oct 15 2024, 12:18 PM
Unknown Object (File)
Oct 15 2024, 12:18 PM
Unknown Object (File)
Oct 15 2024, 12:18 PM
Unknown Object (File)
Oct 15 2024, 12:18 PM
Unknown Object (File)
Oct 15 2024, 12:18 PM
Unknown Object (File)
Oct 15 2024, 12:18 PM
Unknown Object (File)
Oct 15 2024, 12:18 PM
Subscribers

Details

Summary

Restore compaction on web. Because web keeps redux persist storage in the database, and native doesn't, we must also:

  • save redux persist date before restoration
  • put it back after it's restored

We can do that before applying logs, before we can be sure that they won't touch this table.

Moved a few persist constants to a new file because otherwise webworker imported something that used window, which isn't available there.

Depends on D11042

Test Plan
  • Add logging to the native client so that it logs backupID and encryption keys for compaction
  • Upload a new compaction from native with a draft
  • Send restore message
  • Reload web app
  • Check that the draft from native exists now on web. Check that the enabled apps are the same as before restore (redux persist didn't change)

Diff Detail

Repository
rCOMM Comm
Lint
No Lint Coverage
Unit
No Test Coverage

Event Timeline

Harbormaster returned this revision to the author for changes because remote builds failed.Feb 12 2024, 7:31 AM
Harbormaster failed remote builds in B26763: Diff 37002!
web/database/worker/db-worker.js
247 ↗(On Diff #37072)

Where does this message get dispatched? Is that in a later diff?

web/redux/persist-constants.js
2 ↗(On Diff #37264)

As far as I am concerned you can get these data directly by calling library API and defining them here is redundant. cc @kamil

web/database/worker/backup.js
48–51 ↗(On Diff #37264)

Same as here: https://phab.comm.dev/D11044#inline-67443. Calls to sqliteQueryExecutor need special error handling.

web/redux/persist-constants.js
2 ↗(On Diff #37264)

I think you even should. THe library doesn't give guarantees that persist will be stored under this key every time.

web/database/worker/db-worker.js
247 ↗(On Diff #37072)

Sorry, I missed this comment. I've been dispatching the message manually for now:

const response = await databaseModule.schedule({
  type: workerRequestMessageTypes.BACKUP_RESTORE,
  authMetadata: {
    userID: currentUserInfo.id,
    deviceID: 'dummy',
    accessToken: 'dummy',
  },
  backupID: 'XXX',
  backupDataKey:'XXX',
  backupLogDataKey: 'XXX',
});

But it might make sense to add some testing staff-only screen (like tunnelbroker or backup on native) to call it (with backupID, backupDataKey, backupLogDataKey specified by the user).

web/redux/persist-constants.js
2 ↗(On Diff #37264)

You can see that the library:

  • Creates the key from combination of rootKey and rootKeyPrefix link
  • The default value for rootKeyPrefix is persist: link

While the library exposes the default value in the constants file, I think the way I did it here is safer.

If in the future for some reason of the comm developer will want to change the key prefix they will realise that they need to change the restore logic too.

I'm passing the rootKeyPrefix defined here as a config to the redux persist so the library can't change it without us noticing -> that would be a breaking change.

kamil added inline comments.
web/types/worker-types.js
3 ↗(On Diff #37264)
This revision is now accepted and ready to land.Feb 21 2024, 4:54 AM