Page MenuHomePhabricator

[backup-service] make `user_data` and `user_keys` optional in `BackupData`
ClosedPublic

Authored by kamil on Tue, Nov 5, 9:10 AM.
Tags
None
Referenced Files
Unknown Object (File)
Wed, Nov 20, 4:53 PM
Unknown Object (File)
Wed, Nov 20, 5:09 AM
Unknown Object (File)
Sun, Nov 17, 9:06 PM
Unknown Object (File)
Fri, Nov 15, 12:10 PM
Unknown Object (File)
Fri, Nov 15, 10:58 AM
Unknown Object (File)
Thu, Nov 14, 1:14 AM
Unknown Object (File)
Wed, Nov 13, 1:51 AM
Unknown Object (File)
Tue, Nov 12, 8:03 PM
Subscribers

Diff Detail

Repository
rCOMM Comm
Lint
No Lint Coverage
Unit
No Test Coverage

Event Timeline

kamil held this revision as a draft.
kamil published this revision for review.Wed, Nov 6, 3:45 AM
kamil added inline comments.
native/native_rust_library/src/backup/upload_handler.rs
199–209

Depending on what files will be generated we're going to upload User Keys, or User Data, or both

services/commtest/tests/backup_integration_test.rs
60

not sure what is best pattern for this

shared/backup_client/src/lib.rs
59–84

this is strange but we need to maintain order, otherwise backup service can fail to parse Multiplart

86–88

We always want to upload at least one, and depending on data we're gone chose endpoint (see below)

services/commtest/tests/backup_integration_test.rs
60

This is good

shared/backup_client/src/lib.rs
59–84

This is normal - Backup service is designed in such a way that expects these fields in order. So is Blob service.

86–96

I'd also put this above creation of Form::new() etc to early exit when data and keys are both none

This revision is now accepted and ready to land.Thu, Nov 7, 12:38 AM

address review

shared/backup_client/src/lib.rs
86–96

Good call, thanks