Error reporting

Conserve error reporting

Status: Partly implemented.

Goals for error reporting

A major goal for Conserve is that, as much as possible, it continues working even when some errors occur: for example if some files in the backup are corrupted or missing, it should be still able to both restore and to write new backups.

As a result many errors are non-fatal errors. A lower-level function may return an Err if it cannot complete its task, but the caller may be able to continue.

However, non-fatal errors are not silently ignored:

• Errors are visible on stderr from the CLI.
• Tests can observe what errors occurred, and either assert that there were no errors, or that specific errors occurred. This must be possible for both API and CLI tests.
• The CLI can also write out errors as JSON for consumption by other tools (including CLI tests.)
• The CLI exits with a distinct non-zero exit code if non-fatal errors occurred.

Additional goals:

• Errors are reported incrementally as they occur.
• Information about non-fatal errors is not lost if the operation as a whole is interrupted or fails.

Approach

Errors should be reported through the Monitor object, which is passed to most functions. This is a trait that can have different implementations for tests, the CLI, or other users.

The Monitor is responsible for writing errors to tracing if that's desired. Library code can write other info/debug/trace messages to tracing as well, but should not write errors there.

The Monitor can remember the number of errors, the full content of errors, or write them to a file etc.

Transition

Previously, many errors were reported through tracing::error!, and a special tracing subscriber was used to count errors. We're moving away from this approach so that we can capture more structured errors.

In some cases errors are reported in the stats returned from a function, which helps with testing but makes the errors not observable if the function fails overall, so this is gradually being removed.