Depending on older Jackson version causes deserialization to fail with extraneous fields

[zach-lf]

This was working today but started breaking every time around 1pm est.

Attempting to use ChatCompletionResults.choice.message() always throws OpenAIInvalidDataException stating that message is invalid. Here's an example:

com.openai.errors.OpenAIInvalidDataException: message is invalid, received {role=assistant, content={"results":[{"score":100,"languageCode":"en"}]}, refusal=null, annotations=[]}

(is refusal meant to be nullable?)

[RobertCraigie]

Thanks for the report, would you be able to share a full example snippet?

[zach-lf]

Here's a mostly complete snippet:

ChatCompletionCreateParams.Builder builder = ChatCompletionCreateParams.builder();

builder.addSystemMessage("You will be given text, you must identify languages in the text by their two digit ISO 639-1 language code and give them a presence score from 0 - 100 based on how much they are used in the text.");
builder.addUserMessage("Identify the languages in the following text: " + text);

ResponseFormatJsonSchema.JsonSchema.Schema schema =
    ResponseFormatJsonSchema.JsonSchema.Schema.builder()
        .putAdditionalProperty("type", JsonValue.from("object"))
        .putAdditionalProperty(
            "properties",
            JsonValue.from(
                Map.of(
                    "results", Map.of(
                        "type", "array",
                        "items", Map.of(
                            "type", "object",
                            "properties", Map.of(
                                "languageCode", Map.of("type", "string"),
                                "score", Map.of("type", "number")
                            )
                        )
                    )
                )
            )
        )
        .build();

builder
    .model("gpt-4-omni")
    .temperature(0.0d)
    .topP(1.0d)
    .n(1)
    .logprobs(false)
    .maxCompletionTokens(2048)
    .presencePenalty(0.0d)
    .frequencyPenalty(0.0d)
    .responseFormat(ResponseFormatJsonSchema.builder()
        .jsonSchema(ResponseFormatJsonSchema.JsonSchema.builder()
            .name("language-detection-results")
            .schema(schema)
            .build())
        .build())
    .user("assistant");

ChatCompletion chatCompletionResult = openAiClient.chat().completions().create(builder.build());

chatCompletionResult.choice().message(); // this kills the java

[RobertCraigie]

Thanks! We're investigating.

[izian]

We are also seeing this today. We were just doing a POC demo to the company for an OpenAI integration and it failed. The exception was
Caused by: com.openai.errors.OpenAIInvalidDataException: 'message' is invalid, received {role=assistant, content={***REDACTED OUR JSON RESPONSE VALID PER SCHEMA***}, refusal=null, annotations=[]} at com.openai.core.JsonField.getRequired$openai_java_core(Values.kt:101) at com.openai.models.ChatCompletion$Choice.message(ChatCompletion.kt:316) at com.openai.models.ChatCompletion$Choice.validate(ChatCompletion.kt:354) at com.openai.models.ChatCompletion.validate(ChatCompletion.kt:121)

it appears annotations=[] is new and because it's unexpected, it's invalid

[izian]

Appears that my issue was as a result of missing updates to the version, I will try again with latest but I can see it fixed here
3216ffa#diff-1fc18ba9e933f721de439529dfd69eebe583c0caeebef374792fcbd3772a17cc

[TomerAberbach]

First of all, the code snippet from this comment seems not to compile. Did you typo @zach-lf?

I modified the example like so for testing:

OpenAIClient client = OpenAIOkHttpClient.fromEnv();

ChatCompletionCreateParams.Builder builder = ChatCompletionCreateParams.builder();

builder.addSystemMessage(
        "You will be given text, you must identify languages in the text by their two digit ISO 639-1 language code and give them a presence score from 0 - 100 based on how much they are used in the text.");
builder.addUserMessage("Identify the languages in the following text: " + "Hello World");

ResponseFormatJsonSchema.JsonSchema.Schema schema = ResponseFormatJsonSchema.JsonSchema.Schema.builder()
        .putAdditionalProperty("type", JsonValue.from("object"))
        .putAdditionalProperty(
                "properties",
                JsonValue.from(Map.of(
                        "results",
                        Map.of(
                                "type",
                                "array",
                                "items",
                                Map.of(
                                        "type",
                                        "object",
                                        "properties",
                                        Map.of(
                                                "languageCode", Map.of("type", "string"),
                                                "score", Map.of("type", "number")))))))
        .build();

builder.model(ChatModel.GPT_4O_MINI)
        .temperature(0.0d)
        .topP(1.0d)
        .n(1)
        .logprobs(false)
        .maxCompletionTokens(2048)
        .presencePenalty(0.0d)
        .frequencyPenalty(0.0d)
        .responseFormat(ResponseFormatJsonSchema.builder()
                .jsonSchema(ResponseFormatJsonSchema.JsonSchema.builder()
                        .name("language-detection-results")
                        .schema(schema)
                        .build())
                .build())
        .user("assistant");

ChatCompletion chatCompletionResult = client.chat().completions().create(builder.build());

System.out.println(chatCompletionResult.choices().stream()
        .map(ChatCompletion.Choice::message)
        .collect(toList()));

After doing that, the example works fine. I'm not able to reproduce any issue. We actually didn't make any changes to the SDK at 1pm EST. The Responses API was released at around 3pm EST. So maybe there was an ongoing issue with the API, not the SDK.

[izian]

After doing that, the example works fine. I'm not able to reproduce any issue. We actually didn't make any changes to the SDK at 1pm EST. The Responses API was released at around 3pm EST. So maybe there was an ongoing issue with the API, not the SDK.

From my inspection, the SDK changed recently to add the annotations field to the message response. In response to or in anticipation of the API change. It seems that on the latest latest release we might not be seeing this issue anymore.

It didn't seem to matter what the request was, all requests were failing to validate the response due to the empty new field

The validation is strict in this SDK, so the presence of extraneous data causes it to fail. I think it would be cool to have a forward compatible validation mode.

[zach-lf]

From my inspection, the SDK changed recently to add the annotations field to the message response. In response to or in anticipation of the API change. It seems that on the latest latest release we might not be seeing this issue anymore.

This was the issue. And I would agree that the validation is way too strict.

[TomerAberbach]

After doing that, the example works fine. I'm not able to reproduce any issue. We actually didn't make any changes to the SDK at 1pm EST. The Responses API was released at around 3pm EST. So maybe there was an ongoing issue with the API, not the SDK.

From my inspection, the SDK changed recently to add the annotations field to the message response. In response to or in anticipation of the API change. It seems that on the latest latest release we might not be seeing this issue anymore.

I don't think I've seen evidence that the SDK broke due to a change in the SDK.

If you still believe this is the case, then please provide a full reproducible example that compiles as well as the version of the SDK you're using with it.

It didn't seem to matter what the request was, all requests were failing to validate the response due to the empty new field

The validation is strict in this SDK, so the presence of extraneous data causes it to fail. I think it would be cool to have a forward compatible validation mode.

The SDK is already forwards compatible with non-breaking changes to the API. It does not throw for extraneous fields. They will simply go into the additionalProperties bucket.

It will also not complain that the response mismatches the SDK's expectations unless you try to access the specific field that mismatches (or unless you call validate()). See here for more info: https://github.com/openai/openai-java#response-validation

[izian]

I don't think I've seen evidence that the SDK broke due to a change in the SDK.

I'm saying a change to the SDK has fixed the issue. The API changed, and the SDK validates strict, and the field was missing in the SDK, so it failed validation, but the SDK just udpated (yesterday? depends on time zones) and the field annotations is now in the SDK so the validation passes

[TomerAberbach]

I don't think I've seen evidence that the SDK broke due to a change in the SDK.

I'm saying a change to the SDK has fixed the issue. The API changed, and the SDK validates strict, and the field was missing in the SDK, so it failed validation, but the SDK just udpated (yesterday? depends on time zones) and the field annotations is now in the SDK so the validation passes

If that's true, then we should be able write an example snippet that uses an older SDK version and fails because of the new annotations field, but I ran this snippet on an old SDK version and I get this output:

[ChatCompletionMessage{content={"results":[{"languageCode":"en","score":100}]}, refusal=null, role=assistant, audio=, functionCall=, toolCalls=, additionalProperties={annotations=[]}}]

As you can see, the annotations field, which is unknown to this older version of the SDK, is gracefully handled by the additionalProperties map.

---

To be clear, I appreciate the issue report, but this is why I still don't think the issue is what you say it is. I do really want to understand what happened here, which is why I'm asking for a reproducible example.

[TomerAberbach]

I think I might know what happened!

The SDK is compiled against Jackson 2.18, and if I run my code snippet with that version, then annotations ends up in the additionalProperties bucket, but if I downgrade to Jackson 2.17, then the same code snippet throws that error.

It seems like maybe the folks on this issue are:

• Depending on the SDK
• Depending specifically on an older Jackson version, which seems to not handle the @JsonAnySetter on the additionalProperties correctly

I guess the older Jackson version ends up getting chosen at runtime for some reason.

[TomerAberbach]

Yeah, I think we're depending on this feature, which was released in 2.18.1

[TomerAberbach]

Can folks who encountered this issue:

• Confirm they are depending on a version of Jackson older than 2.18.1
• Let me which dependency management tool they are using (e.g. Gradle, Maven, etc.)

[zach-lf]

Yup I'm on an older version of jackson (2.14.2), and using Maven.
Also thank you for looking into this so thoroughly!