You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
The text was updated successfully, but these errors were encountered:
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.
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.
czechboy0
changed the title
ServerError's description of the underlying error (underlyingErrorDescription) can elides the error description unless it is a LocalizedError
ClientError/ServerError's underlyingErrorDescription only produces meaningful output for LocalizedErrors
Oct 4, 2024
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 toString(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
The text was updated successfully, but these errors were encountered: