Repository navigation
HTTP 400 / preconditionFailed should be retried #2723
Description
Activity
I have investigated and implemented a fix for this issue.
Root Cause:
The _should_retry_response function in googleapiclient/http.py relied on HTTP response codes to trigger retries but previously only parsed the JSON error details for403 Forbiddenstatuses (specifically looking foruserRateLimitExceededandrateLimitExceeded). It did not extend this logic to400 Bad Requesterrors.Solution:
I updated _should_retry_response to parse the JSON content for both 403 and 400 status codes.
If the API returns a400 Bad Request, the client will examine the JSON error response block, and if the"reason"is either"failedPrecondition"or"preconditionFailed", the response is now flagged to be retried with exponential backoff.Changes made:
- googleapiclient/http.py: Refactored the JSON parsing block in _should_retry_response to apply to
http_client.BAD_REQUESTas well. Added a condition to returnTruefor retrying when encountering afailedPreconditionreason. - tests/test_http.py: Added a test_retry_400_failed_precondition mock test to verify the client correctly enters the sleep/retry loop rather than failing fast when a 400 preconditions error is received.
It handles the issue perfectly using the project's existing error-parsing conventions. Let me know if you need anything else!
- googleapiclient/http.py: Refactored the JSON parsing block in _should_retry_response to apply to
- added and removed
on Jun 15, 2026
Environment details
google-api-python-clientversion: n/aSteps to reproduce
Intermittent HTTP 400 / preconditionFailed on Gmail API. A casual web search suggests that other Google APIs also issue preconditionFailed. At least in my use case, retrying with exponential backoff always works. I cannot assert that in all use cases that this is the correct behavior.
Code example
N/A
Stack trace