Details
Details
Diff Detail
Diff Detail
- Repository
- rCOMM Comm
- Lint
No Lint Coverage - Unit
No Test Coverage
Event Timeline
native/native_rust_library/src/backup/upload_handler.rs | ||
---|---|---|
199–209 ↗ | (On Diff #45634) | 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 ↗ | (On Diff #45634) | not sure what is best pattern for this |
shared/backup_client/src/lib.rs | ||
59–84 ↗ | (On Diff #45634) | this is strange but we need to maintain order, otherwise backup service can fail to parse Multiplart |
86–88 ↗ | (On Diff #45634) | 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 ↗ | (On Diff #45634) | This is good |
shared/backup_client/src/lib.rs | ||
59–84 ↗ | (On Diff #45634) | This is normal - Backup service is designed in such a way that expects these fields in order. So is Blob service. |
86–96 ↗ | (On Diff #45634) | I'd also put this above creation of Form::new() etc to early exit when data and keys are both none |
Comment Actions
address review
shared/backup_client/src/lib.rs | ||
---|---|---|
86–96 ↗ | (On Diff #45634) | Good call, thanks |