fix: 修复了多图输入情况下转发失效的问题#1714
Conversation
Greptile SummaryThis PR fixes two bugs in the OpenAI image gateway's outbound transformer:
Confidence Score: 4/5The fix is targeted and correct; the only concern is a fragile boundary-extraction pattern in one test that could produce a false-positive pass if the Content-Type format changes. Both production changes (allowlist functions and the image[] field name) directly address the described upstream rejections and are well-covered by new tests. The test boundary extraction uses strings.TrimPrefix rather than proper MIME parsing, which is brittle but does not affect production behaviour. llm/transformer/openai/image_outbound_test.go — specifically the multipart boundary extraction in TestBuildImageEditRequest_MultipleImagesUsesArrayField. Important Files Changed
Flowchart%%{init: {'theme': 'neutral'}}%%
flowchart TD
A[buildImageGenerationAPIRequest] --> B{APIFormat?}
B -->|ImageVariation| C[buildImageVariationRequest]
B -->|ImageEdit| D[buildImageEditRequest]
B -->|default| E[buildImageGenerateRequest]
C --> F{"supportsImageVariationResponseFormat\nmodel is empty or dall-e-2"}
D --> G{len formFiles > 1?}
G -->|Yes| H["imageFieldName = image-array"]
G -->|No| I["imageFieldName = image"]
H & I --> J{"supportsImageEditResponseFormat\nmodel == dall-e-2"}
E --> K{"supportsImageGenerationResponseFormat\nmodel == dall-e-2 or dall-e-3"}
F -->|true| L[inject response_format]
F -->|false| M[omit response_format]
J -->|true| N[inject response_format]
J -->|false| O[omit response_format]
K -->|true| P[inject response_format]
K -->|false| Q[omit response_format]
Reviews (1): Last reviewed commit: "fix: 修复了多图输入情况下转发失效的问题" | Re-trigger Greptile |
| httpReq, err := ot.buildImageEditRequest(req, "test-key") | ||
| require.NoError(t, err) | ||
|
|
||
| reader := multipart.NewReader(bytes.NewReader(httpReq.Body), strings.TrimPrefix(httpReq.Headers.Get("Content-Type"), "multipart/form-data; boundary=")) |
There was a problem hiding this comment.
multipart.NewWriter currently always formats the Content-Type as multipart/form-data; boundary=<value>, so this works today, but it bypasses proper MIME parsing. If the format ever gains quoting, extra parameters, or whitespace differences, TrimPrefix will silently return the original string, causing multipart.NewReader to fail to match any parts and the assert.Len assertion to pass with 0 items instead of erroring loudly. mime.ParseMediaType is the robust alternative.
| reader := multipart.NewReader(bytes.NewReader(httpReq.Body), strings.TrimPrefix(httpReq.Headers.Get("Content-Type"), "multipart/form-data; boundary=")) | |
| _, mimeParams, err := mime.ParseMediaType(httpReq.Headers.Get("Content-Type")) | |
| require.NoError(t, err) | |
| reader := multipart.NewReader(bytes.NewReader(httpReq.Body), mimeParams["boundary"]) |
| func supportsImageVariationResponseFormat(model string) bool { | ||
| return model == "" || model == "dall-e-2" | ||
| } |
There was a problem hiding this comment.
model == "") is treated as a supported model, so a default response_format: "b64_json" will be injected into the multipart form. This preserves the pre-existing behaviour, but the intent is now encoded as a silent special case rather than something the caller can reason about. Documenting this in a comment avoids future surprises when someone maintains the allowlist.
| func supportsImageVariationResponseFormat(model string) bool { | |
| return model == "" || model == "dall-e-2" | |
| } | |
| // supportsImageVariationResponseFormat reports whether the given model supports | |
| // the response_format field for image variations. An empty model string is | |
| // treated as dall-e-2 (the API default) and therefore also supported. | |
| func supportsImageVariationResponseFormat(model string) bool { | |
| return model == "" || model == "dall-e-2" | |
| } |
(cherry picked from commit 8025e86)
本次 PR 修复了以下我们在实际测试中发现的两个问题：
response_format字段，导致上游拒绝本次生图请求修复前后：