If the API returns a 401, like if a bad token is passed into the client constructor, all errors will appear as internal error, response body doesn't match error type signature.
This is caused by the error message being non-standard from the API in:
|
// json.Unmarshal doesn't return an error if the response |
|
// body has a different protocol then "ErrorResponse". We |
|
// check here to make sure that errorRes is populated. If |
|
// not, we return the full response back to the user, so |
|
// they can debug the issue. |
|
// TODO(fatih): fix the behavior on the API side |
|
if *errorRes == (errorResponse{}) { |
|
return &Error{ |
|
msg: "internal error, response body doesn't match error type signature", |
|
Code: ErrInternal, |
|
Meta: map[string]string{ |
|
"body": string(out), |
|
"http_status": http.StatusText(res.StatusCode), |
|
}, |
|
} |
|
} |
The response from the API is:
{"error":"invalid_token","error_description":"The access token is invalid","state":"unauthorized"}
The TODO is almost a year old. Is it worth adding a 2nd (deprecated) ErrorResponse type to handle this other structure?
If the API returns a 401, like if a bad token is passed into the client constructor, all errors will appear as
internal error, response body doesn't match error type signature.This is caused by the error message being non-standard from the API in:
planetscale-go/planetscale/client.go
Lines 196 to 211 in 3f6f5f8
The response from the API is:
{"error":"invalid_token","error_description":"The access token is invalid","state":"unauthorized"}The TODO is almost a year old. Is it worth adding a 2nd (deprecated)
ErrorResponsetype to handle this other structure?