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
storage: Uninformative error messages after errors cause timeout #4197
Comments
Thanks for filing this. I actually did not think we attempted to preserve the non-context error currently, so I'll have to do some research to understand what is going on there in internal/retry.go. In any case, we're hoping to add Go 1.13 error wrapping soon, so hopefully that should be enough to resolve the issue (we'd wrap the previous error in the context error in that case). |
This piggybacks on googleapis#4797 to allow storage to expose wrapped service errors when a call retries without success until timeout or cancellation. I also updated all checks for context sentinel errors in storage to use xerrors.Is instead of strict equality. Users of this package should do the same. I'll update the documentation on errors from this package in a subsequent PR. We will have to bump the dependency on the root module before merging this change I believe. Fixes googleapis#4197
This piggybacks on #4797 to allow storage to expose wrapped service errors when a call retries without success until timeout or cancellation. I also updated all checks for context sentinel errors in storage to use xerrors.Is instead of strict equality. Users of this package should do the same. I'll update the documentation on errors from this package in a subsequent PR. We will have to bump the dependency on the root module before merging this change I believe. Fixes #4197
I added wrapping for retried errors that eventually time out. Most errors will now look like this:
To introspect, any of the following should work:
Hope this helps! |
LGTM, thanks! |
Client
Storage
Environment
Local Ubuntu 18.04 machine
Go Environment
(Some lines deleted that reference info internal to my company. If needed I can reproduce this on a non-work machine, but I don't expect my local environment to be very relevant here)
Code
Expected behavior
It should be possible to recover the underlying error that led to the timeout.
Actual behavior
The only error information returned is that the context timed out:
Or using
spew.Dump
instead offmt.Printf
:Additional context
I care about the specific error because some retryable errors can be mitigated on my end: for example, this issue masked an issue caused by attempting to delete the same object many times at once.
I considered filing this as a feature request, but it looks like there's some attempt to do this in the code:
google-cloud-go/internal/retry.go
Lines 42 to 45 in f97bdfa
The text was updated successfully, but these errors were encountered: