Skip to content

Add optional reason to GitLab client error

Timo Furrer requested to merge client-error-reason into master

This is a boring solution that already provides some value, which is that the reader of the debug logs can understand what the particular issue was when calling the authorized proxy user endpoint.

A few considerations that went into this:

  • Reading the body for every ProtoJsonResponderHandler probably doesn't make any since, because it may leak confidential data (trace back, ...) for some endpoints. So, it's probably best to just ask for it explicitly using a new ProtoJsonWithErrBodyResponseHandler option function.
  • The Error() function for the client error won't add something like <unknown> as reason if it isn't set (because it doesn't add additional useful information for the user - e.g. it's done for path.), but conditionally adds the reason if it's set.

A proper solution for this may be to add a new response handler option type that is called for errors. However, that would be a larger refactoring, because today the response handlers have the responsibility to handle eventual errors by themselves and often only they know what an error is.

Closes #418 (closed)

Edited by Timo Furrer

Merge request reports

Loading