Pull Request tweaking error messages

Hi all,

Helpful contributor @stilez has opened a Boulder PR proposing changes to some of our error messages to make them easier to understand:

Since you all spend a lot of time looking at error messages in pasted logs, I wanted to make sure you saw the change and had an opportunity to provide feedback. Is there anything that you see people getting confused by and would like to fix? Do you think these changes are good?

3 Likes

I think it probably is the clients job to make error messages more user readable.

A method to facilitate this is to give every error message its own error code which doesn’t change if the error message would change in the future. Of course new error messages can be added and old ones could be deprecated, but I think Boulder should have some method for “translating” an error message on the client side.

In the light of the above, I think Boulder/ACME itself should be as technically correct as possible. And leave the translating to the client.

I assume ACME response error messages aren’t defined in the ACME RFC?

2 Likes

I think the ones in the PR are largely specializations of acme:error:malformed (https://tools.ietf.org/html/rfc8555#section-6.7).

There’s a balance to strike on the number of error cases that an ACME client has to deal with. malformed should be interpreted as a fatal error (do not retry), and the a human needs to intervene.

I would like to see the website updated with guidance about how to deal with each error type (maybe in the integration guide), and also a description of each error within an error type, for human reference and to be easily DuckDuckGo-able.

The benefit would be that there could be a long explainer for each one, examples of how you might encounter it, how to fix it, etc. Much more info than you can fit into an API error.

I didn’t find the old error message confusing, but the new ones look good too.

2 Likes

I disagree. Clients cannot keep a database of error detail strings used by Boulder and other ACME CAs (these strings can change any time, or suddenly be translated to other languages, …). Clients can only react to the machine-readable part of the error message, which is for all these errors not helpful at all.

And then let the error message in Boulder include a link to that explanation, so that users who find the error message not useful enough can look at the longer explanation.

1 Like

Doesn’t SMTP have a “standard” set of error codes?
How is this so much more and completely different?
Should there be an ACME standard for error codes (RFC)?