fix: avoid runtime panic when the errors field is nil
#236
Conversation
|
This PR will be held back until Travis starts functioning again. |
|
@padamstx This is a trust game. There is no Travis to help you out. Only you and me. 😂 |
| @@ -627,7 +627,11 @@ func getErrorMessage(responseMap map[string]interface{}, statusCode int) string | |||
| var errors Errors | |||
| responseBuffer, _ := json.Marshal(responseMap) | |||
| if err := json.Unmarshal(responseBuffer, &errors); err == nil { | |||
| return errors.Errors[0].Message | |||
| if len(errors.Errors) > 0 { | |||
There was a problem hiding this comment.
Wow, how did we exist for so long with this bug in place? LOL
This must be the first time that a service returned an error response with an explicit null value for "errors".
Please check the other cores to make sure we don't have a similar bug there.
…nil` Signed-off-by: Norbert Biczo <pyrooka@users.noreply.github.com>
|
@pyrooka After I got GH actions working on the main branch (and published a release), I rebased your PR branch on top of the latest main branch, then force-pushed it. Since everything is now green, I'll merge it. |
|
🎉 This PR is included in version 5.18.5 🎉 The release is available on GitHub release Your semantic-release bot 📦🚀 |
This PR adds an extra step to the error message processing chain,
so that the length of the
errorsslice is checked before trying toget the first error from it.