Skip to content

fix(relay): change image[] to image in multipart field name for images/edits - #5331

Closed
Cokefish9527 wants to merge 1 commit into
QuantumNous:mainfrom
Cokefish9527:fix/gpt-image-2-image-relay-multipart
Closed

fix(relay): change image[] to image in multipart field name for images/edits#5331
Cokefish9527 wants to merge 1 commit into
QuantumNous:mainfrom
Cokefish9527:fix/gpt-image-2-image-relay-multipart

Conversation

@Cokefish9527

@Cokefish9527 Cokefish9527 commented Jun 5, 2026

Copy link
Copy Markdown

Summary

Fix Invalid image file or mode errors from Azure DALL-E /images/edits API by correcting the multipart form field name from image[] to image.

Root Cause

When the ConvertImageRequest() method constructs multipart form data for the images/edits relay, it used image[] (PHP array notation) as the field name when multiple image files were collected. Azure's DALL-E API only recognizes the literal field name image — the image[] name causes the API to misinterpret the form structure and return Invalid image file or mode errors.

Investigation

  • Error rate for gpt-image-2 images/edits: 100% (0 successful / all failed)
  • All 5 Azure channels (29/30/31/32/33) return the same error
  • The bug was introduced in v1.1.2 gray period (May 25-27) and carried forward to v1.1.3
  • Earlier versions using image (without brackets) worked correctly
  • Full investigation report: docs/investigation-gpt-image-2-error-rate.md

Fix

Remove the conditional image[] branch — always use image as the multipart file field name.

Testing

  • Verified that Azure DALL-E /images/edits API spec requires image (not image[])
  • Verified that v1.1.2 early gray (May 25) with image worked correctly on Azure channels
  • The fix does not affect multi-reference-image scenarios (Azure only supports 1 base image + 1 mask)

Summary by CodeRabbit

  • Bug Fixes

    • Fixed image upload functionality by correcting form field naming to comply with upstream service specifications and ensure proper request handling.
  • Documentation

    • Added investigation documentation detailing error rate analysis findings, root cause identification (safety filtering, relay configuration issues, channel availability), and remediation procedures including configuration validation, deployment steps, and monitoring recommendations.

…s/edits

Azure DALL-E /images/edits API requires the multipart file field to be
named 'image' (singular), not 'image[]' (PHP array notation). Using
'image[]' causes 'Invalid image file or mode' errors from Azure.

This bug was introduced during v1.1.2 gray period (May 25-27, 2026)
and carried forward to v1.1.3.

Root cause: ConvertImageRequest() in relay/channel/openai/adaptor.go
conditionally set fieldName='image[]' when multiple image files were
collected from the user's multipart form. Azure's API does not
recognize this field naming convention.

Fix: Always use fieldName='image' regardless of image count.

Investigation report: docs/investigation-gpt-image-2-error-rate.md
@coderabbitai

coderabbitai Bot commented Jun 5, 2026

Copy link
Copy Markdown
Contributor

Review Change Stack

Walkthrough

This PR fixes a multipart form field naming bug in Azure DALL-E image edit requests and documents a comprehensive investigation of high error rates in the gpt-image-2 relay. The code change corrects the field name from conditionally using "image[]" to always using "image" per Azure API requirements. The investigation documentation covers three error sources (Azure safety filtering, the fixed multipart bug, and channel unavailability) with remediation steps.

Changes

gpt-image-2 Multipart Field Fix and Investigation

Layer / File(s) Summary
Multipart form field naming correction
relay/channel/openai/adaptor.go
Image upload field name for Azure DALL-E /images/edits requests is changed from conditional "image[]" (when multiple images present) to always use "image" per API requirements.
Error investigation and remediation documentation
docs/investigation-gpt-image-2-error-rate.md
New documentation file detailing investigation results for 93.1% error rate in gpt-image-2 service: three error types (Azure safety filtering, multipart field naming bug, channel unavailability), root cause analysis for each, timeline cross-referencing code commits, and remediation measures including environment information and post-deployment monitoring guidance.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~12 minutes

Possibly related PRs

  • QuantumNous/new-api#2092: Both PRs touch the same multipart form-data "image" handling for image edits—this PR fixes the relay upload field name to always use "image", while the related PR adds logic to read/marshal the "image" form field into the request.
  • QuantumNous/new-api#4646: Both PRs modify relay/channel/openai/adaptor.go's ConvertImageRequest for RelayModeImagesEdits, changing how edit requests are marshaled/handled.
  • QuantumNous/new-api#2338: Both PRs directly impact the RelayModeImagesEdits request path behavior in the same adaptor file.

Suggested reviewers

  • creamlike1024
  • seefs001

Poem

🐰 A hop and a fix, the fields align,
No more image[] in the Azure design,
From 93% errors, the path grows clear,
With docs mapping roots and solutions dear,
One true field name makes the service sing! 🎨

🚥 Pre-merge checks | ✅ 5
✅ Passed checks (5 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The title clearly and specifically describes the main code change: fixing the multipart field name from 'image[]' to 'image' in the images/edits relay endpoint, which directly addresses the root cause of the high error rate documented in the PR objectives.
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check ✅ Passed Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check ✅ Passed Check skipped because no linked issues were found for this pull request.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

@coderabbitai coderabbitai Bot left a comment

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.

Actionable comments posted: 1

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)
relay/channel/openai/adaptor.go (1)

284-284: ⚠️ Potential issue | 🟡 Minor | ⚡ Quick win

Use common.Unmarshal instead of json.Unmarshal.

This line directly calls json.Unmarshal from encoding/json, which violates the coding guideline. All JSON unmarshal operations must use the wrapper function common.Unmarshal() from common/json.go.

♻️ Proposed fix
-			if err := json.Unmarshal(request.THINKING, &thinking); err != nil {
+			if err := common.Unmarshal(request.THINKING, &thinking); err != nil {

As per coding guidelines: All JSON marshal/unmarshal operations MUST use wrapper functions from common/json.go: common.Marshal(), common.Unmarshal(), common.UnmarshalJsonStr(), common.DecodeJson(), or common.GetJsonType(). Do NOT directly import or call encoding/json in business code.

🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@relay/channel/openai/adaptor.go` at line 284, Replace the direct call to
encoding/json's json.Unmarshal in the THINKING handling with the project's
wrapper common.Unmarshal: call common.Unmarshal(request.THINKING, &thinking) and
keep the existing error handling intact; also remove any now-unused
encoding/json import if present and ensure the code uses the common/json.go
wrapper consistently for JSON operations (reference the current use of
json.Unmarshal and the variables request.THINKING and thinking).
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@docs/investigation-gpt-image-2-error-rate.md`:
- Around line 36-40: The fenced code block showing the error message lacks a
language identifier; update the markdown block (the triple-backtick block
containing "status_code=400 / Invalid image file...") to include a language
specifier such as "text" (e.g., ```text) so it renders and lints correctly.

---

Outside diff comments:
In `@relay/channel/openai/adaptor.go`:
- Line 284: Replace the direct call to encoding/json's json.Unmarshal in the
THINKING handling with the project's wrapper common.Unmarshal: call
common.Unmarshal(request.THINKING, &thinking) and keep the existing error
handling intact; also remove any now-unused encoding/json import if present and
ensure the code uses the common/json.go wrapper consistently for JSON operations
(reference the current use of json.Unmarshal and the variables request.THINKING
and thinking).
🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

  • Push a commit to this branch (recommended)
  • Create a new PR with the fixes

ℹ️ Review info
⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: f2fbca30-5283-4ba0-a32f-959638169a06

📥 Commits

Reviewing files that changed from the base of the PR and between 3280584 and 1be99cb.

📒 Files selected for processing (2)
  • docs/investigation-gpt-image-2-error-rate.md
  • relay/channel/openai/adaptor.go

Comment on lines +36 to +40
```
status_code=400
Invalid image file or mode for image 1 (或 image 3),
please check your image file.
```

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.

⚠️ Potential issue | 🟡 Minor | ⚡ Quick win

Add language specifier to fenced code block.

The fenced code block should specify a language identifier for proper rendering and linting compliance.

📝 Proposed fix
-```
+```text
 status_code=400
 Invalid image file or mode for image 1 (或 image 3),
 please check your image file.
🧰 Tools
🪛 markdownlint-cli2 (0.22.1)

[warning] 36-36: Fenced code blocks should have a language specified

(MD040, fenced-code-language)

🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@docs/investigation-gpt-image-2-error-rate.md` around lines 36 - 40, The
fenced code block showing the error message lacks a language identifier; update
the markdown block (the triple-backtick block containing "status_code=400 /
Invalid image file...") to include a language specifier such as "text" (e.g.,
```text) so it renders and lints correctly.

@Cokefish9527

Copy link
Copy Markdown
Author

Closing: PR should target aiapi114 project, not upstream new-api.

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.

1 participant