fix(tools): handle non-UTF-8 HTTP error responses - #7023
Open
SUJALMU2004 wants to merge 1 commit into
Open
Conversation
SUJALMU2004
marked this pull request as ready for review
September 5, 2026 08:35
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Please ensure you have read the contribution guide before creating a pull request.
Link to Issue or Description of Change
1. Link to an existing issue (if applicable):
No matching existing issue was found.
2. Or, if no issue exists, describe the change:
The bug report, reproduction, and fix are provided below, as permitted by CONTRIBUTING.md.
Problem:
RestApiTooldecodes HTTP error bodies withresponse.content.decode("utf-8"). An API that returns a Latin-1 error with a validContent-Typecharset, or an error containing invalid UTF-8 bytes, raisesUnicodeDecodeErrorinstead of returning the tool's normal error dictionary. The decoding error masks the HTTP status and message.Solution: Use
response.text, matching the existing non-JSON success path. HTTPX honors the response charset and replaces undecodable bytes. No new dependency or public API change.Environment: Reproduced on upstream
25f5214c83f56b2fcffd35757e886026632f3c2b(ADK 2.8.0), Windows 11, Python 3.12.10, HTTPX 0.28.1. No model or LiteLLM is required.Steps to reproduce: Run the local HTTP script below against upstream. The first endpoint responds with HTTP 400,
Content-Type: text/plain; charset=iso-8859-1, andb"Acc\xe8s refus\xe9".UnicodeDecodeError: 'utf-8' codec can't decode byte 0xe8 in position 3: invalid continuation byte.Testing Plan
Unit Tests:
Added three regression cases through
RestApiTool.run_async, with a real HTTPX client andMockTransportonly at the network boundary. They cover declared Latin-1, invalid UTF-8, and a missing charset. The existing ASCII HTTP error test retains its exact result assertion and now uses a realhttpx.Response.The affected tests pass on every supported Python version. The full-repository checkbox remains unchecked because the complete
toxmatrix is not verified; see the limitation below.Regression proof on unmodified source: 3 failed, 1 passed; all three new cases fail with
UnicodeDecodeError.With the fix:
The built wheel also passes all 66 tests in
test_rest_api_tool.pyin isolated environments on Python 3.10, 3.11, 3.13, and 3.14 (Python 3.12 is covered by the full OpenAPI suite above):Full-suite limitation: Attempted the repository's full
toxmatrix on Windows, then interrupted the Python 3.10 run after failures in untouched CLI tests. A separate rerun oftests/unittests/cli/conformance/test_generate_markdown_utils.py -xconfirmedUnicodeEncodeErrorwhen_generate_markdown_utils.py:112writes a checkmark using the Windowscp1252encoding. Both that source file and its tests are unchanged from the base commit. The complete full-suite matrix is not verified. GitHub CI currently requires maintainer approval for this first contribution.Formatting and checks: Ruff, isort, pyink, whitespace, license, compliance, and codespell hooks passed. On Windows the
check-new-py-prefixwrapper fails to launch because its shebang uses/bin/bash. Its exact underlying check passed withpython scripts/check_new_py_files.py --new-dir .; only that wrapper was skipped for the commit.Manual End-to-End (E2E) Tests:
uv buildsucceeded. Ran the script below both from the editable checkout and against the built wheel in a clean environment:Each scenario asserts the returned status/message or successful JSON payload. The script uses a real loopback HTTP server, with no cloud credentials or model calls.
Reproduction and local HTTP verification script
Save as
../verify_rest_api_error_decoding.py:Checklist
No public API or documentation changes are needed.
Additional context
Prepared with Codex assistance. The Google CLA check has passed and this PR is ready for review. CI still requires maintainer approval; the full-suite validation limitation is documented above.