New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
drive: FilesGetCall.Download did not unmarshal the body in the error response #752
Comments
Thanks for the issue. I'm not sure why that's the case for this call. Here is what appears to be the relevant function: google-api-go-client/googleapi/googleapi.go Lines 165 to 178 in 84df58a
Note that it doesn't try to parse the body as JSON, per the function comment. It seems that all Error parsing came up for #473. So, let's wait for @codyoss. Notably, https://google.aip.dev/193 doesn't call out media requests as different.
|
Thanks for the issue @aofei. @tbpg I assume this is a special case for storage, at least I know that api does not conform to the aip and has xml endpoints... We could keep using this method for storage and move all other apis to use |
Sounds good to me. |
If a method supports media downloads use CheckResponse. This method provided extra context to errors if the api follow https://google.aip.dev/193. The storage api will continue to use CheckMediaResponse as it does not conform to the aip due to legacy reasons. Fixes: #752
Just now I happened to notice that the
FilesGetCall.Download
threw me this error:The returned
error
is still*googleapi.Error
, which is fine. But in its fields, onlyCode
andBody
have values. This caused me to be unable to handle errors through theErrors
field as usual.So, does this work as designed?
The text was updated successfully, but these errors were encountered: