Skip to content

chore: 调整图像输入size大小限制#1769

Merged
looplj merged 8 commits into
looplj:unstablefrom
sxueck:unstable
Jun 3, 2026
Merged

chore: 调整图像输入size大小限制#1769
looplj merged 8 commits into
looplj:unstablefrom
sxueck:unstable

Conversation

@sxueck

@sxueck sxueck commented Jun 3, 2026

Copy link
Copy Markdown
Contributor

当前图像输入限制为 4MB,这在实际场景下不太实用,本次 PR 将其同步为 Azure 文档的推荐值(50MB)

可参考:https://learn.microsoft.com/en-us/azure/foundry/openai/how-to/dall-e?tabs=command-line%2Ckeyless%2Ctypescript-keyless&pivots=programming-language-studio

@greptile-apps

greptile-apps Bot commented Jun 3, 2026

Copy link
Copy Markdown
Contributor

Greptile Summary

This PR raises the per-image upload limit from 4 MB to 50 MB (matching the Azure OpenAI recommendation), increases the maximum image count from 10 to 16, and recalculates maxImageBodySize accordingly (~816 MB). A regression test covering the previously-rejected 5 MB image is also added.

  • defaultMaxImageFileSize bumped to 50 MB and maxImageCount to 16; maxImageBodySize is now a derived formula rather than a hand-coded constant.
  • buildMultipartJSONBody base64-encodes every image for tracing — at the new limits (16 × 50 MB) this can produce ~2.7 GB in-process per request, which is a meaningful OOM risk under concurrent load.
  • New test TestImageInboundTransformer_TransformRequest_Edit_Multipart_AcceptsImageAboveLegacy4MBLimit validates the relaxed constraint end-to-end.

Confidence Score: 3/5

The limit relaxation itself is correct, but the trace-logging path now base64-encodes up to 800 MB of image data per request, which can exhaust memory under concurrent load.

The core limit change is correct and well-tested. The concern is the trace-logging function that base64-encodes every uploaded image in-process: at 16 x 50 MB a single request can hold ~2.7 GB simultaneously, and concurrent uploads multiply that quickly.

llm/transformer/openai/image_inbound.go — specifically the buildMultipartJSONBody call sites in transformEditRequest and transformVariationRequest.

Important Files Changed

Filename Overview
llm/transformer/openai/image_inbound.go Raises per-file limit from 4 MB to 50 MB, max image count from 10 to 16, and recomputes maxImageBodySize (~816 MB); the base64-logging path for tracing now carries OOM risk at the new limits.
llm/transformer/openai/image_inbound_test.go Adds a regression test uploading a 5 MB image (previously blocked by the 4 MB limit) and asserting it is now accepted; coverage is straightforward and correct.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[Incoming HTTP Request] --> B{len body > maxImageBodySize ~816 MB?}
    B -- Yes --> ERR1[Error: request body too large]
    B -- No --> C[Parse multipart parts]
    C --> D{Part has filename?}
    D -- No: field --> E{len value > maxImageFileSize 50 MB?}
    E -- Yes --> ERR2[Error: field too large]
    E -- No --> F[Store as form field]
    D -- Yes: file --> G{imageCount > 16?}
    G -- Yes --> ERR3[Error: too many images]
    G -- No --> H{len data > maxImageFileSize 50 MB?}
    H -- Yes --> ERR4[Error: file too large]
    H -- No --> I{Allowed MIME type?}
    I -- No --> ERR5[Error: unsupported image type]
    I -- Yes --> J[Append to formData.Images]
    J --> C
    F --> C
    C --> K[buildMultipartJSONBody base64-encodes ALL images for trace logging]
    K --> L[Return llm.Request]
Loading

Comments Outside Diff (1)

  1. llm/transformer/openai/image_inbound.go, line 276-278 (link)

    P1 OOM risk from base64-logging all image data

    buildMultipartJSONBody base64-encodes every image into a JSON blob for tracing. With the new limits (16 images × 50 MB = 800 MB binary), a single request could hold the raw body (~816 MB), all decoded image slices (~800 MB), and the base64 JSON (~1.07 GB) simultaneously — roughly 2.7 GB peak per request. A handful of concurrent uploads could exhaust available memory. Consider either omitting image bytes from the log body entirely, truncating to a small preview, or writing the data to a temp file/object-store reference rather than keeping it in-process.

    Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!

Reviews (1): Last reviewed commit: "feat: raise image upload limits to 50MB ..." | Re-trigger Greptile

maxImageCount = 10
defaultMaxImageFileSize = 50 * 1024 * 1024
maxImageCount = 16
maxImageBodySize = defaultMaxImageFileSize*maxImageCount + 16*1024*1024

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 maxImageBodySize is derived from the compile-time constant defaultMaxImageFileSize, not from the runtime maxImageFileSize variable. If AXONHUB_MAX_IMAGE_FILE_SIZE is set to a value larger than 50 MB, the body-size gate won't reflect it, so the early rejection on line 389 becomes inaccurate. Consider deriving this guard dynamically, or at least document the intentional decoupling.

Suggested change
maxImageBodySize = defaultMaxImageFileSize*maxImageCount + 16*1024*1024
// maxImageBodySize is intentionally based on defaultMaxImageFileSize (not the
// runtime maxImageFileSize) and serves only as a fast-path guard before multipart
// parsing. Per-file size is enforced per-part using maxImageFileSize.
maxImageBodySize = defaultMaxImageFileSize*maxImageCount + 16*1024*1024

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

将其交给用户进行选择,而不是网关层面锁死了大小

@looplj looplj merged commit b6826c1 into looplj:unstable Jun 3, 2026
4 checks passed
junjiangao pushed a commit to junjiangao/axonhub that referenced this pull request Jun 5, 2026
* fix: 修复了多图输入情况下转发失效的问题

* chore: 添加了登陆后页面标题自定义配置项

* Update frontend/src/features/system/components/brand-settings.tsx

Co-authored-by: greptile-apps[bot] <165735046+greptile-apps[bot]@users.noreply.github.com>

* feat: raise image upload limits to 50MB per file and 16 images

---------

Co-authored-by: greptile-apps[bot] <165735046+greptile-apps[bot]@users.noreply.github.com>
Co-authored-by: YuNing Shen <yuning.shen@starbucks.cn>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants