Define Error.Code as authoritative #25
Conversation
| @@ -25,13 +25,19 @@ properties: | |||
| description: | | |||
| Code is a network-specific error code. If desired, this code | |||
| can be equivalent to an HTTP status code. | |||
|
|
|||
| This is considered the authoritative indicator of the cause | |||
| of the error. | |||
| type: integer | |||
| format: int32 | |||
| minimum: 0 | |||
| example: 12 | |||
| message: | |||
There was a problem hiding this comment.
@matheusd We added the new Error.Details field in v1.4.0 to capture different messages related to the context of the error but expect Error.Message to stay the same for all errors of a particular code.
We do not yet assert that this is true in the rosetta-cli yet, but will begin to do so shortly now that we have the Error.Details field.
|
Thanks for posting this PR @matheusd (I think it may be the first external!) ... I clarified a point about Would ❤️ if you repurposed this PR to improve the documentation on these |
|
Updated. Given that the message has to be fixed, should they maybe be recommended to be code-like messages vs descriptive messages? Stuff like |
|
Thanks for writing these descriptions @matheusd! Some small nits around some extra trailing spaces but once those are fixed looks good.
That's a great question. I don't believe we need to restrict all messages to be code-like (descriptive messages may honestly make things more understandable). Consistency of message and code is the most important point here (which your changes already make clear). |
|
(CircleCI didn't get kicked off so I had to close/open the PR) |
This improves the description of the Error model by indicating that error messages must be unique and cannot have contextual information.
(Opening up as a PR directly with the suggested change to clarify this point for implementations and clients but happy to discuss if this isn't the actual intention of the Error Code/Message distinction.)
This makes it explicit that the Code attribute of the Error model is the
authoritative source of truth for the origin of the error, while the
error message is secondary.
It also makes it explicit that the same error code may present multiple
different messages so clients of Rosetta implementations should not rely
on them for error detection and Rosetta backends should make an effort
to present error codes in a granular enough level for clients.