[ADR] Universal Error Specification

[yordis]

Interested?

Every comment, every link to any information about it, and every opinion is appreciated (including the opinionated and strong ones), as small as it could be.

Please participate.

[stale]

This pull request has been automatically marked as "Withdrawn". If this pull request is still relevant, please leave any comment (for example, "bump"), and we'll keep it open. We are sorry that we haven't been able to prioritize reviewing it yet. Your contribution is very much appreciated!.

[acco]

So does /data refer to top-level key? Would be helpful to see an example that uses nesting here.

[yordis]

It is a relative JSON Path Pointer based on` whatever Command Message payload structure.

In this case,

const command = {
  data: {
    currency: "INVALID"
  }
}

[acco]

Should sources be exposed to end users? What if they refer to "meaningless" internal microservices?

I can imagine sources being translated before end user exposure

[yordis]

Should sources be exposed to end users?
Yes

What if they refer to "meaningless" internal microservices?
Then, the clients decide to ignore the source, and there is not much to do on their end.

In practice, you wouldn't have that many of those errors that are not related to a subject from a given Command Message.

[acco]

Interesting to pass the stack trace around. (Assume this is NOT for end user exposure)

A practice we've been experimenting with is wherever we create an error, we also log out through a common error reporting module. Our log contains a correlation ID that we also put on the error.

This means we don't need to put things like stacktraces on the error, as the error will tell us where to find the stacktrace. Curious about your thoughts on this!

[yordis]

I improved my writing.

The intent is that you would strip out the stacktraces out of the content before going out of your system. That information is only helpful to send to logging services.