Bound Codex image generation error previews

[ooiuuii]

Summary

• add a bounded preview reader for streamed Codex image-generation HTTP error responses
• avoid calling response.read() on non-2xx Codex Responses API errors before truncating the displayed message
• keep the existing 500-character diagnostic preview behavior, with an explicit truncation marker for oversized bodies

Fixes #54841

Validation

• uv run --extra dev python -m pytest tests\plugins\image_gen\test_openai_codex_provider.py -q --basetemp .pytest-tmp-codex-image-error-preview (19 passed)
• git diff --check
• autoreview helper unavailable locally (autoreview, agent-autoreview, and codex-autoreview not found)

[tonydwb]

LGTM — Bounds Codex error response reads to 1MB max with a 500-char preview. Clean implementation with good test coverage (bounded preview test confirms truncation behavior).

[teknium1]

Thanks for isolating the Codex streamed-error path; the current-head premise is valid: plugins/image_gen/openai-codex/__init__.py:395-396 still fully reads the error body before truncating its displayed preview.

Problems

• The new iter_bytes() loop in the PR has a byte cap but no hard deadline. A response that yields a prefix and then stalls remains blocked until the Codex client's 300-second read timeout (plugins/image_gen/openai-codex/__init__.py:387).
• Current main already has agent.bounded_response.read_streaming_error_body() (agent/bounded_response.py:56-125), which caps bytes and closes stalled responses after a hard deadline. The new local reader duplicates that responsibility with weaker behavior.

Suggested changes

• Reuse read_streaming_error_body() from _collect_image_b64(), preserving the 500-character user-facing preview. Extend that shared helper if an explicit truncation marker is required.
• Add a provider-level non-2xx streaming regression test; the shared helper already has real-socket oversize/stall coverage in tests/agent/test_bounded_response.py:107-129.

Automated hermes-sweeper review.

[teknium1]

iter_bytes() can block inside the socket read after a partial error body arrives, so this loop does not bound latency. Please reuse agent.bounded_response.read_streaming_error_body(), which applies both a byte cap and a hard deadline by closing stalled responses.

[teknium1]

Heads-up: the error-preview code this PR targets changed on main in 064b6e4 (PR #71635), so this will need a small rebase.

That PR removed the account-capability classifier from _collect_image_b64 and replaced the blind exc.response.text[:500] slice with _summarize_error_body(), which prefers the parsed error.message and falls back to a truncated raw body. Reason: Codex error payloads can carry hundreds of bytes of leading metadata, so head-truncating at 500 chars was returning padding and cutting the actual message off entirely.

That does not resolve what you reported here. Your point stands and is untouched: we still call exc.response.read() inside the httpx.stream(...) context, so the full upstream body is buffered before anything is truncated. Bounding the read is still the right fix, and it's a separate concern from formatting the preview.

Only change needed on your side: the truncation now happens in _summarize_error_body(exc.response.text) rather than inline, so a bounded read should feed that helper instead of replacing the slice. _MAX_ERROR_BODY_CHARS (500) is already defined at module scope, so _CODEX_ERROR_PREVIEW_CHARS in your diff would be a duplicate — reuse the existing constant.

Sorry for the churn, and thanks for the precise write-up on both this and #55248 — the scoping made the overlap easy to check.

[teknium1]

Landed in #111000 (3275ca8). The openai-codex image provider no longer sends a Responses call hosted on a pinned chat model; it POSTs directly to the Codex backend's native images/generations / images/edits endpoints (the route the official Codex client uses). The streamed error path no longer exists (plain POST). Thanks @ooiuuii.