You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is fundamentally an issue with our Google Drive client (and other clients), but tracking it here as it has direct impact.
When calling download_by_id, the Drive client will call to request_raw. request_raw will return the response body directly to the caller without can interference, and leaves it to the caller to perform any necessary error handling. download_by_id does not perform any checking of the response status or headers and instead immediately translates the request body into a bytes::Bytes. At this point, any data about the status of the request has been lost and a caller only has the raw bytes of the response to make determinations on.
In the case of cio, the bytes returned are being treated as a String, assuming that if the client had failed to download the file an error would have been returned. The visible results of this is the server error message being written to the database as if it was a successful download. Specifically we have seen this when failing to download a chat log file. This resulted in an error body for a 401 error overwriting the stored chat log data.
To resolve this we will need to address a couple sub-issues:
Update Google Drive client to return errors when download files fails
Only write chat log data when a file is successfully downloaded (currently unwrap_or_default is used which will overwrite with an empty string on failure)
The text was updated successfully, but these errors were encountered:
This is fundamentally an issue with our Google Drive client (and other clients), but tracking it here as it has direct impact.
When calling
download_by_id
, the Drive client will call torequest_raw
.request_raw
will return the response body directly to the caller without can interference, and leaves it to the caller to perform any necessary error handling.download_by_id
does not perform any checking of the response status or headers and instead immediately translates the request body into abytes::Bytes
. At this point, any data about the status of the request has been lost and a caller only has the raw bytes of the response to make determinations on.In the case of
cio
, the bytes returned are being treated as a String, assuming that if the client had failed to download the file an error would have been returned. The visible results of this is the server error message being written to the database as if it was a successful download. Specifically we have seen this when failing to download a chat log file. This resulted in an error body for a401
error overwriting the stored chat log data.To resolve this we will need to address a couple sub-issues:
unwrap_or_default
is used which will overwrite with an empty string on failure)The text was updated successfully, but these errors were encountered: