Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

v1.28.0 breaks API requests that specify a response format without a JSONSchema #818

Closed
gspeicher opened this issue Aug 7, 2024 · 6 comments
Labels
bug Something isn't working

Comments

@gspeicher
Copy link

Describe the bug
The addition of the JSONSchema field to type ChatCompletionResponseFormat has broken API requests that specify ResponseFormat as openai.ChatCompletionResponseFormatTypeJSONObject.

To Reproduce

        req := openai.ChatCompletionRequest{
                // ...
                ResponseFormat: &openai.ChatCompletionResponseFormat{
                        Type: openai.ChatCompletionResponseFormatTypeJSONObject,
                },
        }
        resp, err := o.Client.CreateChatCompletion(context.Background(), req)

Expected behavior
API requests should continue to work as before.

Screenshots/Logs
The API is responding with:

Unknown parameter: 'response_format.json_schema'.

Environment (please complete the following information):

  • go-openai version: 1.28.0
  • Go version: 1.22.5
  • OpenAI API version: v1
  • OS: MacOS 14.6 (23G80)

Additional context
The problem is that omitempty does not respect the empty value for JSONSchema field since it is defined as a non-pointer type. If it is defined instead as a pointer to ChatCompletionResponseFormatJSONSchema then it will be correcly omitted from the marshaled JSON when not in use.

type ChatCompletionResponseFormat struct {
	Type       ChatCompletionResponseFormatType       `json:"type,omitempty"`
	JSONSchema ChatCompletionResponseFormatJSONSchema `json:"json_schema,omitempty"`
}
@gspeicher gspeicher added the bug Something isn't working label Aug 7, 2024
@gspeicher
Copy link
Author

Tagging @eiixy as the original author of the breaking PR.

@tylergannon
Copy link
Contributor

@gspeicher see #820. Meanwhile if you want to get started using the new api before this gets merged, you can use my fork. Just update your go.mod to use the following replace directive:

replace github.com/sashabaranov/go-openai => github.com/tylergannon/go-openai v1.28.1

@gspeicher
Copy link
Author

Thanks, @tylergannon! While you're in there, maybe you can check out my note in #813 about changing the definition of the ChatCompletionResponseFormatJSONSchema type.

type ChatCompletionResponseFormatJSONSchema struct {
	Name        string                `json:"name"`
	Description string                `json:"description,omitempty"`
	Schema      jsonschema.Definition `json:"schema"`
	Strict      bool                  `json:"strict"`
}

My hope is that we can change the type of Schema to the json.Marshaler interface (from encoding/json) instead of forcing consumers to use jsonschema.Definition to declare the JSON schema. Even the godoc comments for that type state:

It is fairly limited, and you may have better luck using a third-party library.

but explicitly defining Schema as above means you have no choice except to use jsonschema.Definition. Also worth mentioning that jsonschema.Definition already satisfies the json.Marshaler interface so all of the examples and tests should continue to work unchanged.

@fonsecabc
Copy link

fonsecabc commented Aug 7, 2024

I am also having this problem, is there any fix to it yet or the only option is to not use the response format? I really need to use the structured return because I tried structuring the return just by prompt but it kept returning me with ```json tags before and after the json object and I couldn't find a way to extract the json from it.

@EduardoMoraesRitter
Copy link

I had a problem with this today.

@sashabaranov
Copy link
Owner

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

5 participants