shollyman
shollyman
Timestamp precision loss is a known issue with the wire format of BQ tabledata responses. The recently-beta BQ storage api [addresses this](https://cloud.google.com/bigquery/docs/reference/storage/#schema_conversion) and other issues. Would making it possible for...
Opened 128990665 internally as an FR for BigQuery team.
The `retryableError` predicate is used for retrying API method interactions (e.g. starting a query, getting table metadata, etc). In this case, it seems like you started a job, and the...
The `Inserter` abstraction is used for streaming data. If you're getting an internalError from the backend I'd expect it to retry with the existing predicate as the 'internalError' reason should...
Yes, per the AIP guidance blindly retrying on http 500 is not recommended. However, a 500 response that includes a structured error may be retried, that's what the `retryableError` function...
For posterity, here's the function from 1.8.0: ``` func retryableError(err error) bool { e, ok := err.(*googleapi.Error) if !ok { return false } var reason string if len(e.Errors) > 0...
The error is trying to communicate that the remote end of the grpc AppendRows grpc stream connection is going away. It is unclear if that's in response to your request...
> When should I open the new stream(s)? In this single-writer pattern, when the existing stream closes. You can potentially issue concurrent appends by managing multiple connections. Regardless, you also...
No worries, thanks for following up with your feedback. Some more information that may be useful to you: In the first case (draining error), the response is coming back from...
Committing of rows within a single AppendRowsRequest is either all or none. You don't need to worry about partial commit. You can potentially constrain the throughput on a single `ManagedStream`...