[Bug]: Inlining an image whose pixel dimensions exceed the provider's limit crashes the request instead of degrading gracefully

[xiaoka76]

QwenPaw Version

2.1.0 (Docker image xk-qwenpaw:v2.1.0f1, unmodified)

Description

Sending an image that is smaller than the 2 MB inline cap but whose pixel dimensions exceed the provider's image limit crashes the request with a MODEL_EXECUTION_ERROR and ends the conversation. QwenPaw checks only the byte size of images before inlining them; it does not check pixel dimensions. The provider's pixel limit is therefore the last line of defence, and crossing it raises an unhandled BadRequestError instead of degrading (compress/resize or replace with a text placeholder).

This was discovered while attempting to implement #7201 (separate per-provider max_image_bytes / max_video_bytes / max_audio_bytes): raising the byte cap lets more images reach the provider, which makes this underlying crash more likely to trigger. Please do not relax the 2 MB inline default until pixel-dimension checking/compression is in place (see Additional Notes).

Related Issue(s): #7201

Security considerations: none

Component(s) Affected

• Core / Backend (app, agents, config, providers, utils, local_models)
• Console (frontend web UI)
• Channels (DingTalk, Feishu, QQ, Discord, iMessage, etc.)
• Skills
• CLI
• Documentation (website)
• Tests
• CI/CD
• Scripts / Deploy

Environment

• QwenPaw version: 2.1.0
• OS: Docker (nested)
• Install method: Docker image xk-qwenpaw:v2.1.0f1
• Python version (if applicable): 3.11

Steps to Reproduce

1. Prepare an image that is < 2 MB in file size but whose total pixels exceed the provider's image limit (e.g. 10240×6400 = 65,536,000 pixels > 36,000,000). Attached test image: too_many_pixels_10240x6400.jpg (0.50 MB).
2. Configure a vision provider (e.g. Doubao / Volcano Ark) and start a conversation.
3. Send the image as a user message.
4. The request inlines the image (it passes the 2 MB byte check) and the provider rejects it, crashing the conversation.

Actual vs Expected

• Actual: The request dies with MODEL_EXECUTION_ERROR — the exception propagates through retry_chat_model → middleware → agentscope _agent._call_model → raise last_exception from None, and the conversation ends.
• Expected: The image should degrade gracefully — either be resized/compressed to within the provider's pixel limit before sending, or be replaced with a text placeholder (e.g. [Image unavailable: ...]) so the conversation can continue.

Logs / Screenshots

openai.BadRequestError: Error code: 400 - {'error': {'message': 'litellm.BadRequestError: OpenAIException - {"error":{"code":"InvalidParameter","message":"Image 0 failed: Image exceeds the maximum allowed total pixels. Current dimensions: 10240x6400 = 65536000 pixels. Maximum allowed: 36000000 pixels. ..."}'}}
...
File "agentscope/agent/_agent.py", line 2414, in _call_model
    raise last_exception from None

Additional Notes

• Pixel limit (Doubao / Volcano Ark vision): width > 14 px and height > 14 px; width×height ∈ [196, 36,000,000]; aspect ratio ∈ [1/150, 150]. Outside these, the provider returns InvalidParameter / BadRequest (400).
• Root cause: QwenPaw's media pipeline (provider / context / tool-call / user-message handling) only validates image byte size (the 2 MB inline cap), not pixel dimensions. There is no pixel check or graceful fallback before the provider call.
• Do not relax the 2 MB default for now. The byte cap currently acts as an accidental guard: larger images get replaced with a [Image unavailable: ...] placeholder at the freeze stage. Raising it (as [Feature]: Separate per-provider max_image_bytes / max_video_bytes / max_audio_bytes caps and expose them in the provider advanced settings #7201 proposes) increases the chance that a pixel-oversized image reaches the provider and crashes. Pixel-dimension detection/compression should land first.
• Related downstream effects:
  1. Larger-than-2 MB images (the majority of real photos) are flagged "too large", and the model must compress them via a tool to view them, losing detail.
  2. The Visual Compact (visual compression) feature does not touch native images (they are "correctness-owned by the normal formatter") — its synthetic pages are size-bounded (CANVAS_MAX_HEIGHT=728), so it neither causes nor can mitigate this crash.
• Attached test image: too_many_pixels_10240x6400.jpg (file 0.50 MB < 2 MB; 10240×6400 = 65,536,000 px > 36,000,000 px; aspect ratio 1.60 within limits).

[github-actions]

Welcome to QwenPaw! 🐾

Hi @xiaoka76, this is your 11th issue.

We'll review your issue soon. Thank you for supporting QwenPaw!