[andrewpark-scaleai]

Why

The goal is that every failure of an agent run leaves enough in the logs to debug it. The Gemini agent's in-sandbox LiteLLM proxy falls short. When its call to LiteLLM fails at the transport layer, it returns 502 {"detail": "gemini upstream request failed: "} with an empty reason, because str() of many httpx exceptions (ReadTimeout, RemoteProtocolError, ReadError) is empty. A reader cannot tell a slow upstream from an unreachable one. The proxy also does not log non-2xx LiteLLM responses on the passthrough path, and none of its logs say which deployment answered.

What

• Transport errors on the passthrough and the vertex bridge now include the exception class in the 502 detail (ConnectError: ..., or repr(e) when the message is empty). They also log a warning with event=litellm_upstream_transport_error, proxy and error_type.
• Non-2xx LiteLLM responses are logged on both paths with event=litellm_upstream_error_response, proxy, upstream_status, and whichever of x-litellm-model-id, x-litellm-model-api-base and x-litellm-model-group the response carries. Absent headers are left out. The response relayed to the CLI is unchanged.

The only change a caller sees is the longer 502 detail text.

Test

uv run --extra dev pytest tst/unit/agents/gemini/ -q gives 156 passed. The new and updated tests in test_litellm_proxy.py use a fake httpx transport, check the log record fields with caplog, and fail without the change (6 failures against origin/main source).

Confidence Score: 5/5

The PR appears safe to merge; the previous finding is fixed and no new actionable issues remain.

Summary

The PR makes Gemini proxy failures easier to debug.

• Gemini proxy failures now name the exception and deployment in logs.

No new actionable issues were found. Tests were not rerun.

_{Reviews (3) · Last reviewed commit: "Gemini proxy: name the upstream error bo..." · Reviewed by Greptile}