mirror of
https://github.com/openclaw/openclaw.git
synced 2026-08-14 06:33:09 -06:00
Sukhdeep
a7396255d0
The litellm image provider built edit requests as a JSON body with
`images: [{image_url}]`, but LiteLLM's POST /v1/images/edits is a multipart
endpoint following OpenAI's edits schema: the reference image must be an
uploaded file part named `image` (or `image[]`). LiteLLM never finds an `image`
key in a JSON body and fails before contacting the upstream provider:
HTTP 500 aimage_edit() missing 1 required positional argument: 'image'
so every image edit through this provider fails. Plain generation is unaffected.
No JSON variant works. Verified against LiteLLM v1.82.3 with a real 512x512 PNG:
plural `images` 500s as above; singular `image` as a data URL or bare base64,
string or array, returns HTTP 400 "Invalid image file or mode". Only multipart
succeeds. Note that singular `image` clears the 500 and reaches the provider,
which looks like progress but never delivers usable bytes.
Switch buildEditRequest to return { kind: "multipart", form }, which
createOpenAiCompatibleImageGenerationProvider already routes to
postMultipartRequest — matching the built-in openai and deepinfra providers.
A single reference uses the `image` part name and multiple use repeated
`image[]` parts; LiteLLM accepts either as List[UploadFile] and merges them,
erroring only when both appear in one request.
Also drops the now-unused imageToDataUrl helper and its imports.
Tests: the existing edit test asserted the buggy JSON shape, so it now asserts
a multipart request, that postJsonRequest is not called, and the single-image
part name; a new test covers repeated image[] parts for multiple references.
Verified end-to-end against LiteLLM v1.82.3 with a live agent: single-reference
and multi-image edits both return real images; both failed with the 500 before.