storage: timeout errors are not always wrapped when a func was retried #9720
Labels
api: storage
Issues related to the Cloud Storage API.
type: bug
Error or flaw in code with unintended results or allowing sub-optimal usage patterns.
Errors are wrapped when calling the
run
function ininvoke.go
, when the error was retried and there was a context timeout/deadline exceeded.For example, this is what an error looks like after the retry was exhausted with a timeout on obj.Attrs:
retry failed with context deadline exceeded; last error: googleapi: Error 400: ...
However, there are (at least) 2 cases when those errors are not wrapped:
When
MaxAttempts
is reached; this is what an error looks like after the number of max attempts was exhausted:googleapi: Error 400: ...
On object uploads with HTTP; This is what an error looks like after retry timeout exhausted on object write:
context deadline exceeded
Here is repro code:
I'm also concerned about timeouts that happen inside the call on L72 in
invoke.go
, in the unlucky case that the timeout is exhausted right before that call and the call checks the timeout and errors. I haven't looked at this code path to see if that is possible and if it would return an unwrapped error, but we should verify.The text was updated successfully, but these errors were encountered: