NoWorkingMirrorError swallows error messages

Description of issue:

When tuf raises a NoWorkingMirrorError, it displays the list of URLs with the corresponding exception classes, but the error message of each exception is lost.

Current behavior:

I got the following error in some logs:

tuf.exceptions.NoWorkingMirrorError: No working mirror was found:
  'xxx': ReplayedMetadataError()

You can reproduce the issue easily with the following script:

import tuf.exceptions

error = tuf.exceptions.ReplayedMetadataError('myrole', '1.2.3', '1.2.1')
print(str(error))
mirror_error = tuf.exceptions.NoWorkingMirrorError({'myurl': error})
print(str(mirror_error))

Which outputs:

Downloaded 'myrole' is older ('1.2.3') than the version currently installed ('1.2.1').
No working mirror was found:
  '': ReplayedMetadataError()

Expected behavior:

I want to get the actual content of ReplayedMetadataError.

[awwad]

That actually won’t fix the missing information in the logs, in part because updater’s loggers don’t call str() on NoWorkingMirrorError, so changing NoWorkingMirrorError.__str__() won’t fix it. Example logging here.

This problem is basically a result of some fancy exception classes that have calculated error messages produced by __str__(), but no __repr__() methods. When those (ReplayedMetadataError, BadHashError, some others) are put in a NoWorkingMirrorError, the calculated messages don’t show up in the logs. Others, like BadVersionNumberError, still show up fine in logs (or a script like the above) when they’re put into a NoWorkingMirrorError.

The easiest fix here is probably one of these options:

1. change NoWorkingMirrorError.__str__() as @adityasaky suggests, and also change all the logger.error() calls to both mention the particular exception types and then call str() (since otherwise you’d lose the individual exception types in the logs)
2. or add a __repr__() method to ReplayedMetadataError and similar exceptions

I think the pythonic answer is probably 2, since repr() is intended for this kind of debugging.

[trishankatdatadog]

Ah, @therve is one of us at Datadog, thanks for helping out 😃