rustic check always reports success...

[kapitainsky]

even if there are errors.

For example I deleted some random pack file and run repository check:

$ rustic check
[INFO] using config ./rustic.toml
...
[00:00:00] listing packs...
[ERROR] pack 00050289 is referenced by the index but not present! To repair: 'rustic repair index'.
[00:00:00] listing packs...
...
[00:00:07] checking trees...              ████████████████████████████████████████          2/2

$ echo $?
0

The same when some packs are corrupted etc. Actually it looks like it always return 0:) Always happy that all is fine even if nothing is:)
It makes rustic check pretty much useless for any automation.

Of course there is a workaround - old good restic:

$ restic check
...
check all packs
pack 0005028953e699e8cdac37ec96d73c2277e6359da72fd64e8930a29afe0d483d: does not exist
check snapshots, trees and blobs
[0:25] 100.00%  2 / 2 snapshots

The repository is damaged and must be repaired. Please follow the troubleshooting guide at https://restic.readthedocs.io/en/stable/077_troubleshooting.html .

Fatal: repository contains errors

$ echo $?
1

but when switching to rustic I hoped that I can do it fully.

[aawsome]

Yes, we know. There is rustic-rs/rustic_core#222 and rustic-rs/rustic_core#224 but it got somehow stuck with a general discussion about error handling philosophies.

Having check return errors will also improve the quality of our integration tests (which do call check on the repositories), so this is high on our priority list.

[kapitainsky]

it has not landed in v10.0 yet?

[aawsome]

unfortunately not, I'll try to work next on it...

[aawsome]

I tried to overwork rustic-rs/rustic_core#224 a bit to get it ready and merged soon ;-)

[aawsome]

With 0.10.1, rustic check now returns a return code of 1 if the check failed.