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 | 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 | |