damjad opened a new issue, #40419:
URL: https://github.com/apache/beam/issues/40419
### What happened?
## Bug description
`InsertBatchofRowsCallable.call()` calls
`insert.execute().getInsertErrors()`. The HTTP request goes through
`RetryHttpRequestInitializer`, but the BQ response body is parsed by
`parseAs()` **after** `executeUnparsed()` returns — outside the scope of the
retry handler.
A `SocketTimeoutException` (or connection reset / broken pipe) thrown during
chunked response body reading therefore lands in the `catch (IOException e)`
block where `getErrorInfo(e)` returns `null` (it's not a
`GoogleJsonResponseException`). The code immediately re-throws it as
`RuntimeException`, bypassing both the configured `InsertRetryPolicy` and the
outer `insertAll` retry loop entirely.
## Impact
On Dataflow, this causes a bundle retry for every occurrence. The bundle
re-processes all rows in the affected batch from scratch. We observed 65 such
events in a 2-week production window on a streaming pipeline, with 85%
clustered on a single day when BQ was slow to respond.
## Steps to reproduce
1. Use `BigQueryIO.write()` with `Method.DEFAULT` (streaming inserts)
2. Simulate a slow BQ response where the chunked HTTP body read times out
mid-stream
3. Observe `RuntimeException` wrapping `SocketTimeoutException` propagating
out of `insertAll` rather than the rows being retried via `InsertRetryPolicy`
## Root cause
In
`BigQueryServicesImpl.DatasetServiceImpl.InsertBatchofRowsCallable.call()`:
```java
} catch (IOException e) {
GoogleJsonError.ErrorInfo errorInfo = getErrorInfo(e);
if (errorInfo == null) {
// SocketTimeoutException lands here — not a
GoogleJsonResponseException
serviceCallMetric.call(ServiceCallMetric.CANONICAL_STATUS_UNKNOWN);
result.updateFailedRpcMetrics(start, start,
BigQuerySinkMetrics.UNKNOWN);
throw e; // no retry — bypasses InsertRetryPolicy and outer backoff
loop
}
```
`getErrorInfo()` only handles `GoogleJsonResponseException`. A
`SocketTimeoutException` during response body parsing is a plain `IOException`,
so it falls into the `errorInfo == null` branch and is thrown immediately.
## Expected behaviour
Transient network errors should be routed through the pipeline's configured
InsertRetryPolicy and the outer insertAll retry loop (max 5 retries via
`INSERT_BACKOFF_FACTORY`), consistent with how BQ-reported transient errors
like backendError are handled.
## Environment
- Apache Beam 2.70.0 (confirmed present in latest master as of 2026-10-05)
- Dataflow runner, streaming mode
### Issue Priority
Priority: 2 (default / most bugs should be filed as P2)
### Issue Components
- [ ] Component: Python SDK
- [x] Component: Java SDK
- [ ] Component: Go SDK
- [ ] Component: Typescript SDK
- [ ] Component: IO connector
- [ ] Component: Beam YAML
- [ ] Component: Beam examples
- [ ] Component: Beam playground
- [ ] Component: Beam katas
- [ ] Component: Website
- [ ] Component: Infrastructure
- [ ] Component: Spark Runner
- [ ] Component: Flink Runner
- [ ] Component: Prism Runner
- [ ] Component: Twister2 Runner
- [ ] Component: Hazelcast Jet Runner
- [x] Component: Google Cloud Dataflow Runner
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
