invalid_request_error: 'content' is a required property

[schneiderfelipe]

Hi @64bit!

TL;DR: async-openai seems to silently create unexpected, invalid requests because the OpenAI API expects the content field be present, even if it is null.

The content field seems to be required in situations that, AFAIK, is only mentioned en passant in the OpenAI API reference documentation:

content (string or null) Required
The contents of the message. content is required for all messages, and may be null for assistant messages with function calls.

(Emphases mine.) As such, I don't know if this should be addressed in async-openai. Depending on how you interpret the documentation, it might be the case that async-openai is in fact violating the API contract. In any case, I had such a bad time debugging that I think it's worth creating an issue.

The issue

The following fails by using curl directly:

$ curl https://api.openai.com/v1/chat/completions -u :$OPENAI_API_KEY -H 'Content-Type: application/json' -d '{"model":"gpt-3.5-turbo","messages":[{"role":"user","content":"What is the weather like in Boston?"},{"role":"assistant","function_call":{"name":"get_current_weather","arguments":"{\"location\":\"Boston, MA\"}"}},{"role":"function","content":"{\"forecast\":[\"sunny\",\"windy\"],\"location\":\"Boston, MA\",\"temperature\":\"72\",\"unit\":null}","name":"get_current_weather"}],"functions":[{"name":"get_current_weather","description":"Get the current weather in a given location","parameters":{"properties":{"location":{"description":"The city and state, e.g. San Francisco, CA","type":"string"},"unit":{"enum":["celsius","fahrenheit"],"type":"string"}},"required":["location"],"type":"object"}}],"temperature":0.0,"max_tokens":null}'
{
  "error": {
    "message": "'content' is a required property - 'messages.1'",
    "type": "invalid_request_error",
    "param": null,
    "code": null
  }
}

The second message {"role":"assistant","function_call":{"name":"get_current_weather","arguments":"{\"location\":\"Boston, MA\"}"}} does not contain a content field. The solution is to insert one. Both "content":null and "content":"" work. So there's a difference between omitting the content field and having "content":null.

Why

I created the failing example above by serializing a CreateChatCompletionRequest directly. The issue lies in skipping serializing the content field if it is None:

async-openai/async-openai/src/types/types.rs

Lines 724 to 727 in 3776935

	/// The contents of the message.
	/// `content` is required for all messages except assistant messages with function calls.
	#[serde(skip_serializing_if = "Option::is_none")]
	pub content: Option<String>,

The current workaround is to set content to an empty string:

aot::ChatCompletionRequestMessageArgs::default()
    .role(aot::Role::Assistant)
    .function_call(aot::FunctionCall { name, arguments })
    .content("")
    .build()?

Again, depending on how you interpret the OpenAI API documentation, this behaviour might break the API contract. What do you think?

[64bit]

Hi @schneiderfelipe - Thank you for a detailed description of the issue.

It does sound like the issue is showstopper and it makes sense to fix this in async-openai and make it work with current behavior of OpenAI API.

So the fix is to remove #[serde(skip_serializing_if = "Option::is_none")] attribute from content field?

[schneiderfelipe]

Yes, I think so, at least for the presented use case. This makes me sad actually, the current behaviour of async-openai feels like the right one, but for no reason OpenAI wants to make a distinction between the absence of a content field and the presence of "content":null.

[64bit]

This fix is released in v0.14.1