ouyangbo/hermes-agent
1
0
Fork 0
Code Issues Pull Requests Actions 9 Packages Projects Releases Wiki Activity

fix(agent): classify "media exceeds size limit" as image_too_large

Browse Source 
MiniMax's Anthropic-compatible endpoint rejects an oversized native image
part with "media exceeds size limit: max 10485760 bytes (2013)" — no
occurrence of the word "image", so none of _IMAGE_TOO_LARGE_PATTERNS
matched. The 400 fell through to _REQUEST_VALIDATION_PATTERNS (the body
is type: invalid_request_error) and classified as format_error /
non-retryable.

That skipped the image-shrink recovery in conversation_loop, which is
gated on FailoverReason.image_too_large. Because the oversized part is
already baked into history as a tool_result image block, and the context
compressor rewrites text but not image data, every later turn re-sent the
same bytes and failed identically — the session stayed dead until the
user forked it.

Match on the "media" fragment, mirroring the existing "image exceeds"
entry so reworded vendor variants are caught too. A non-image media
rejection routed here is safe: the shrink pass finds no image parts,
returns False, and the caller surfaces the original error unchanged.

Fixes #76039
This commit is contained in:
Koduri Mahesh Bhushan Chowdary
2026-08-01 11:15:03 +02:00
committed by Teknium
parent 98a84783c7
commit b3f4f50771
2 changed files with 41 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
agent/error_classifier.py
+10
View File
@@ -284,6 +284,16 @@ _IMAGE_TOO_LARGE_PATTERNS = [
"image dimensions exceed", # Anthropic: "image dimensions exceed max allowed size: 8000 pixels"
"dimensions exceed max allowed size", # Anthropic dimension-cap (wording variant)
"max allowed size: 8000", # Anthropic dimension-cap (explicit pixel ceiling)
# Vendors that reject the same oversized image without using the word
# "image". MiniMax's Anthropic-compatible endpoint returns
# "media exceeds size limit: max 10485760 bytes (2013)" for a native
# image part above its 10 MB ceiling (#76039). Matched on the "media"
# fragment to mirror "image exceeds" above and catch reworded variants.
# A non-image media rejection (audio/video) that lands here is safe: the
# shrink pass finds no image parts, returns False, and the caller
# surfaces the original error unchanged.
"media exceeds",
"media too large",
# "request_too_large" on a request known to contain an image → image is
# the likely culprit; we still try the shrink path before giving up.
]