tritone
Repos
18
Followers
10
Following
1

Auto-generated Google APIs for Go.

3283
907

Google Cloud Client Libraries for Go.

3112
1018

Events

storage: EOF errors during calls

Sure that's fine. I flagged the linked case with @neild on the Go team, so it's in his queue, but might take some time to address (and obviously any fix at that level will not be available until the next Go language release).

Created at 2 days ago

chore(bigquery): fix typos in commented vars (#2768)

Created at 3 days ago
chore(bigquery): fix typos in commented vars
Created at 3 days ago
storage.buckets.setIamPolicy has no preconditions implemented in .NET and hence will retry successfully

Should this be triaged as a FR (to add precondition support to this method) or as a bug (to fix something that's currently broken)?

Created at 3 days ago
storage: EOF errors during calls

You can customize retry settings on a BucketHandle or ObjectHandle or customize them per call; it would look something like this:

func myErrorFunc(err error) bool {
  ...
}
client.Bucket("my-bucket").Object("my-object").Retryer(WithErrorFunc(myErrorFunc)).Attrs()

See https://pkg.go.dev/cloud.google.com/go/storage#ObjectHandle.Retryer for details.

I don't think it's safe to add retries for EOF to the library for the reasons I mentioned above and because it's just generally not intended to be a retryable error. The issue that you linked is interesting though; I can flag it with the Go team. It sounds like EOF is really not the appropriate error for net/http to be raising in this case.

Created at 3 days ago
storage: EOF errors during calls

Thanks for the issue. So, the difference between EOF and io.ErrUnexpectedEOF is that the latter occurs only when we expected to receive a certain number of bytes, but got an EOF before hitting that number. I believe the net/http client determines this using the Content-length header; e.g. if the response from the server has Content-length: 852, then we expect the JSON response body to have 852 bytes. Therefore if we get ErrUnexpectedEOF we know that the payload was not complete (perhaps due to connection issues) and we should retry the request.

I'm not totally sure how you could get a normal EOF error from a call to ObjectHandle.Attrs and don't think I've encountered this before myself. I would be curious to see the Content-length header as well as the actual length of the payload to try and debug.

In the meantime, I think it's safe for you to add EOF as a retryable error using WithErrorFunc specifically for calls to Attrs; however there are other library methods where it wouldn't be safe as this is used as a sentinal error internally (in the case of Reader or externally (in the case of iterator methods).

Created at 1 week ago
Blob.exists() making multiple calls

@nitishxp I was not able to reproduce this locally; I only see one call to GET the object when running it myself. I suspect there is an issue with your logging, or maybe your code is calling the snippet more times than you expect.

Created at 1 week ago
Blob.exists() making multiple calls

The first call is from client.get_bucket(), which makes an API call to fetch bucket metadata. You can skip this call by using client.bucket() instead I believe.

Let me know if this does the trick:

event_bucket = client.bucket(<bucket>)
blob = event_bucket.blob("path to blob")
if blob.exists():
   pass
Created at 1 week ago
Attention

https://github.com/dotnet/dotnet-api-docs/pull/7387

Created at 1 week ago
Attention

I don't see how this is relevant to this repo. Please re-open with more context if there is anything in particular that you would like us to look at.

Created at 1 week ago