Images API doesn't automatically detect content type

[nuclear-bean]

TLDR: HttpRequestBodies.kt sets inappropriate ContentType which ends in 400 response when working with ImageEditParams object

While working on #453 I've noticed a problem with uploading files to /images/edits endpoint

Problem:
Any attempt to upload an image with client.images().edit ends in 400: Invalid type for 'image': expected a file, but got a string instead. response

Stacktrace:

Exception in thread "main" com.openai.errors.BadRequestException: 400: Invalid type for 'image': expected a file, but got a string instead.
	at com.openai.errors.BadRequestException$Builder.build(BadRequestException.kt:88)
	at com.openai.core.handlers.ErrorHandler$withErrorHandler$1.handle(ErrorHandler.kt:48)
	at com.openai.services.blocking.ImageServiceImpl$WithRawResponseImpl$edit$1.invoke(ImageServiceImpl.kt:109)
	at com.openai.services.blocking.ImageServiceImpl$WithRawResponseImpl$edit$1.invoke(ImageServiceImpl.kt:107)
	at com.openai.core.http.HttpResponseForKt$parseable$1$parsed$2.invoke(HttpResponseFor.kt:14)
	at kotlin.SynchronizedLazyImpl.getValue(LazyJVM.kt:74)
	at com.openai.core.http.HttpResponseForKt$parseable$1.getParsed(HttpResponseFor.kt:14)
	at com.openai.core.http.HttpResponseForKt$parseable$1.parse(HttpResponseFor.kt:16)
	at com.openai.services.blocking.ImageServiceImpl.edit(ImageServiceImpl.kt:42)
	at com.openai.services.blocking.ImageService.edit(ImageService.kt:34)
	at com.openai.example.ImageEditExample.main(ImageEditExample.java:44)

Reason:
Multipart form data Content-Type set to text/plain instead of image/jpeg which end API doesn't accept

ImageServiceImpl.kt L106 brekapoint values:

Reproducible example: https://github.com/nuclear-bean/openai-java/blob/invalid-content-type-example/openai-java-example/src/main/java/com/openai/example/ImageEditExample.java

I've also prepared a (VERY dirty) fix - let's call it a demonstration on what what solves the issue. You can find it here - nuclear-bean@91f4f29 - this branch runs and completes the task with no problems.

However, I don't have the time now to dive deeper into the SDK strucutre and find an appropriate approach. My guess is that ImageEditParams object should accept a filename param and derive Content-Type from it (?). If you could direct me towards an accaptable solution I can work from there or I will get back to it later

There's a workaround mentioned here #452 (comment). If this is the only intended way of setting the Image maybe fun image(image: Image) should be removed from ImageEditParams.Builder since using it always ends in 400 error?

[davidglevy]

I'm having this issue as well, - many thanks @nuclear-bean , will look at this "dirty fix" as a workaround. I spent too long last night with different variations of the image constructor thinking it was a "me problem".

[nuclear-bean]

@davidglevy Happy to help! If your goal is simply to get things working in your project, the best approach is probably to wrap ImageEditParams.Image in a MultipartField object, as shown here: #452 (comment). This way you don't need to mess with SDK’s Kotlin code.

[TomerAberbach]

So the bug here is actually that the API should automatically detect what kind of content it is based on the file signature

There is work planned for this so I won't be doing this work in the SDK

For now the workaround is to use MultipartField