Determine this is the right repository
Summary of the issue
#17489 ("avoid SSLError retry loop", released in 3.42.2) added requests.exceptions.SSLError to a new _UNSTRUCTURED_NON_RETRYABLE_TYPES and short-circuits _should_retry on it
(retry.py:46,76-77).
The PR's motivating case is insert_rows_json, but _should_retry is not that method's predicate — it is the base predicate for every retry surface in the client. As a result a single transient TLS reset now fails any API call, where 3.40.1 retried it as the requests.exceptions.ConnectionError subclass it is.
Expected vs. actual
A transient SSLEOFError (peer or middlebox dropping the socket mid-handshake) is a transport error and was retried to DEFAULT_RETRY's 600 s deadline in 3.40.1 — retry.py there has no _UNSTRUCTURED_NON_RETRYABLE_TYPES at all, so _should_retry fell through to the isinstance check against _UNSTRUCTURED_RETRYABLE_TYPES, which contains requests.exceptions.ConnectionError (and requests makes SSLError a subclass of it deliberately). In 3.42.2 the same blip raises on the first occurrence.
API client name and version
google-cloud-bigquery: 3.42.2 (first release with the change) — still present in 3.43.0
Reproduction steps: code
No response
Reproduction steps: supporting files
No response
Reproduction steps: actual results
No response
Reproduction steps: expected results
No response
OS & version + platform
Container-Optimized OS (GKE, Cloud Composer 3)
Python environment
Python: 3.11
Python dependencies
No response
Additional context
What we actually observe in production
Deferred BigQueryInsertJobOperator tasks (Airflow 3.2 / Composer 3) poll jobs.get every 4 s. Since upgrading to an image carrying 3.42.2, polls fail like this — and each failure fails the task and re-submits the query, on jobs that are RUNNING and healthy:
HTTPSConnectionPool(host='bigquery.googleapis.com', port=443): Max retries exceeded with url: /bigquery/v2/projects/<project>/jobs/<job>?projection=full&location=EU (Caused by SSLError(SSLEOFError(8, '[SSL: UNEXPECTED_EOF_WHILE_READING] EOF occurred in violation of protocol')))
49 such events across ~20 different DAGs in ~19 h; zero on the same workload while it ran 3.40.1. Note the URL family: jobs.get — a GET with no request body, so no schema can be involved. Note also that google.auth.transport.requests.AuthorizedSession mounts HTTPAdapter(max_retries=3) on the auth session only, so nothing below the client retries the data request either: identical resets on an IAM refresh call recover silently, while jobs.get fails outright.
Determine this is the right repository
Summary of the issue
#17489 ("avoid SSLError retry loop", released in 3.42.2) added
requests.exceptions.SSLErrorto a new_UNSTRUCTURED_NON_RETRYABLE_TYPESand short-circuits_should_retryon it(
retry.py:46,76-77).The PR's motivating case is
insert_rows_json, but_should_retryis not that method's predicate — it is the base predicate for every retry surface in the client. As a result a single transient TLS reset now fails any API call, where 3.40.1 retried it as therequests.exceptions.ConnectionErrorsubclass it is.Expected vs. actual
A transient
SSLEOFError(peer or middlebox dropping the socket mid-handshake) is a transport error and was retried toDEFAULT_RETRY's 600 s deadline in 3.40.1 —retry.pythere has no_UNSTRUCTURED_NON_RETRYABLE_TYPESat all, so_should_retryfell through to theisinstancecheck against_UNSTRUCTURED_RETRYABLE_TYPES, which containsrequests.exceptions.ConnectionError(andrequestsmakesSSLErrora subclass of it deliberately). In 3.42.2 the same blip raises on the first occurrence.API client name and version
google-cloud-bigquery: 3.42.2 (first release with the change) — still present in 3.43.0
Reproduction steps: code
No response
Reproduction steps: supporting files
No response
Reproduction steps: actual results
No response
Reproduction steps: expected results
No response
OS & version + platform
Container-Optimized OS (GKE, Cloud Composer 3)
Python environment
Python: 3.11
Python dependencies
No response
Additional context
What we actually observe in production
Deferred
BigQueryInsertJobOperatortasks (Airflow 3.2 / Composer 3) polljobs.getevery 4 s. Since upgrading to an image carrying 3.42.2, polls fail like this — and each failure fails the task and re-submits the query, on jobs that areRUNNINGand healthy:49 such events across ~20 different DAGs in ~19 h; zero on the same workload while it ran 3.40.1. Note the URL family:
jobs.get— a GET with no request body, so no schema can be involved. Note also thatgoogle.auth.transport.requests.AuthorizedSessionmountsHTTPAdapter(max_retries=3)on the auth session only, so nothing below the client retries the data request either: identical resets on an IAM refresh call recover silently, whilejobs.getfails outright.