ServerError's description of the underlying error (underlyingErrorDescription) can elides the error description unless it is a LocalizedError

[francescomikulis]

Motivation

A client of the OpenAPIGenerator was reporting an error, which in the logs appeared as a very unhelpful:
(MyClassTypeScope.(unknown context at $107abc012).MyErrorType error 0.)
It seems the this issue is caused by the fact that ServerError.underlyingErrorDescription is not falling back to String(describing: underlyingError), but using another representation that is not very useful in practice.

Proposed solution

Please consider moving the error description mechanism that surfaces the content of the underlying error to use String(describing: underlyingError) instead of the current mechanism.

Alternatives considered

Forcing all clients to conform to LocalizedError in order to get good logging for an error is error-prone.

Additional information

No response

[czechboy0]

Hi @francescomikulis,

yeah this is currently somewhat intentional, to prevent leaking potentially sensitive data unintentionally through logs.

That said, I am open to discussing this more and potentially reconsider.

@fabianfett, can you chime in here with your experience in this area from the Postgres client, and @FranzBusch as well maybe? cc @simonjbeaumont

[simonjbeaumont]

Should we have different behaviour for debug and production servers? ISTR this is how some of the web frameworks behave with regard to providing the error in the response payload.

[czechboy0]

Right, some do, I suspect this issue is about making the behavior consistent between transports. There is the extra consideration of the wrapping of the thrown error in a ServerError, and how those descriptions interact.