fix: avoid TypeError when a 403 error body is a JSON array

[kwy404]

Root cause

_should_retry_response handles two shapes of 403 error bodies. The dict branch reads the reason from data["error"]["errors"][0]["reason"], but the list branch (bodies like [{"error": {...}}], the format reported in #225) reads data[0]["error"]["errors"]["reason"]. errors is a list, so indexing it with "reason" raises TypeError. That exception is not in the caught tuple (UnicodeDecodeError, ValueError, KeyError), so it escapes HttpRequest.execute(): a list-wrapped rateLimitExceeded 403 is never retried, and any other list-wrapped 403 surfaces as TypeError: list indices must be integers or slices, not str instead of HttpError.

from googleapiclient.http import _should_retry_response
body = b'[{"error": {"code": 403, "errors": [{"reason": "rateLimitExceeded"}]}}]'
_should_retry_response(403, body)  # main: TypeError, this branch: True

The existing test_no_retry_403_list_fails did not catch this because its LIST_NOT_CONFIGURED_RESPONSE fixture is not valid JSON (the object is missing its braces), so json.loads fails before the list branch runs.

Fix

Index the first entry of errors, the same way the dict branch does. One line in googleapiclient/http.py. The fixture gets its missing braces so the existing test really exercises the list branch.

Test

• New test_retry_403_list_rate_limit: a list-wrapped rateLimitExceeded 403 followed by a 200 should retry once and return {}.
• Existing test_no_retry_403_list_fails, now with valid JSON: a list-wrapped accessNotConfigured 403 should raise HttpError without retrying.

Before the fix both fail with TypeError: list indices must be integers or slices, not str. After the fix both pass, and the rest of the suite gives the same results as on main.

Checklist

• Make sure to open an issue as a bug/issue before writing your code (no separate issue; the bug and a reproduction are above)
• Ensure the tests and linter pass (black and the CI flake8 selection are clean on the changed files)
• Code coverage does not decrease (if any source code was changed)
• Appropriate docs were updated (if necessary): not needed

[gemini-code-assist]

Code Review

This pull request resolves a bug where the error reason was incorrectly accessed from a dictionary instead of a list within the JSON response. It also updates the test suite with a valid mock response and adds a new test case for retrying on 403 rate limit errors. The reviewer recommends implementing defensive type and boundary checks when parsing the nested JSON response to prevent potential unhandled exceptions like TypeError or IndexError.

[gemini-code-assist]

While indexing data[0]["error"]["errors"][0]["reason"] fixes the immediate TypeError when errors is a list, this line is still highly vulnerable to other unhandled exceptions. Since the except block only catches (UnicodeDecodeError, ValueError, KeyError), any of the following scenarios will raise an unhandled TypeError, IndexError, or AttributeError and crash the request execution:

1. data is an empty list [] (raises IndexError).
2. data is not a list (e.g., None, int, bool, or a string) (raises TypeError).
3. data[0] is not a dictionary (raises TypeError).
4. data[0]["error"] is not a dictionary (raises TypeError or AttributeError if using .get()).
5. data[0]["error"]["errors"] is an empty list or not a list (raises IndexError or TypeError).

To make this completely robust and prevent any unhandled exceptions from escaping _should_retry_response, we should perform defensive type and boundary checks before accessing these nested keys.

Suggested change

	reason = data[0]["error"]["errors"][0]["reason"]
	reason = None
	if isinstance(data, list) and data and isinstance(data[0], dict):
	error = data[0].get("error")
	if isinstance(error, dict):
	errors = error.get("errors")
	if isinstance(errors, list) and errors and isinstance(errors[0], dict):
	reason = errors[0].get("reason")

[kwy404]

Thanks, good catch. These shapes already raised on main (for example, an empty errors list raised TypeError there and IndexError after my first commit), but they still escape as something other than HttpError, which is what this PR is meant to fix. Rather than nesting type checks, I added IndexError and TypeError to the existing except tuple. Those shapes now go down the same path as other invalid content: log a warning, no retry, and the caller gets an HttpError. I also added test_no_retry_403_malformed_body, which covers [], an empty errors list, ["x"] and null.

[kwy404]

Pushed a follow up commit that makes _should_retry_response treat malformed 403 bodies (empty lists, non-dict entries, null) as invalid content instead of raising, with a test for those cases.