acim
commented
6 months ago The idea behind this is to parse the response body whenever possible so I would actually suggest to drop this condition completely and always parse response body. In case that decode fails, return ErrStatus. The rest of the logic should remain the same. Could you try this implementation, please? If not, I can try this in a branch but it would be nice if you could test it. Thank you.
I tried creating a DNS record using this library, and because of an invalid input on my side the record could not be created. (The value I passed was not valid for the record type and the API returned an HTTP status code of 422 Unprocessable Entity.)
Instead of returning the error to my business logic though, the error was silently discarded in the library.
The faulty code appears to check for certain "successful" status codes, returning an error for all other status codes. In reality, however, the condition only fails if the status code is 404. This is because
!=operator should probably be a==instead, similar to the other status codes.