Page MenuHomePhabricator

[backup] Introduce backup error
ClosedPublic

Authored by michal on Aug 25 2023, 9:49 AM.
Tags
None
Referenced Files
Unknown Object (File)
Sat, May 4, 6:26 PM
Unknown Object (File)
Sat, May 4, 6:26 PM
Unknown Object (File)
Sat, May 4, 6:22 PM
Unknown Object (File)
Sat, May 4, 5:58 PM
Unknown Object (File)
Apr 16 2024, 11:51 PM
Unknown Object (File)
Apr 15 2024, 1:53 AM
Unknown Object (File)
Apr 13 2024, 9:02 PM
Unknown Object (File)
Apr 10 2024, 11:01 PM
Subscribers

Details

Summary

ENG-4380

Catch-all error for all errors that will be able to come up during handling of backup requests. For now it only has errors for blob client, but it will be expanded in the future diffs.

Test Plan

Create a service:

.service(web::resource("/hello").route(web::get().to(
       |blob: web::Data<BlobServiceClient>| async move {
         let _ = blob.get("asdasd").await.map_err(BackupError::from)?;
         Ok::<&str, BackupError>("world")
       },
     )))

Test a few different scenarios: blob error not available (not running), blob not existing

Diff Detail

Repository
rCOMM Comm
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

bartek added inline comments.
services/backup/src/error.rs
28 ↗(On Diff #30327)

Btw - have you tested {err} vs {err:?} ? - Sometimes Debug is more meaningful and sometimes Display - I've never found a single good way.

This revision is now accepted and ready to land.Aug 25 2023, 1:04 PM
services/backup/src/error.rs
28 ↗(On Diff #30327)

Just tested it and it seems Display is fine. In this case (our own errors) I think we should try and keep the Display the preferred way (this is also why I prefer thiserror over derive_more because it requires you to be more explicit when it comes to the messages)