[BUG] azure-openai: Error serializing error response from OpenAI with Content-Type: text/plain

[dsibilio]

Describe the bug
Azure OpenAI runs into Caused by: java.lang.IllegalStateException: Unsupported text Content-Type Type: class java.lang.Object when trying to serialize the error response (e.g.: 401 invalid_api_key) from OpenAI, if OpenAI includes the Content-Type: text/plain header in the response instead of the usual Content-Type: application/json; charset=utf8.

It seems recently OpenAI started occasionally replying with Content-Type: text/plain even though the response looks the same as usual, e.g.:

{
    "error": {
        "message": "Incorrect API key provided: XXX. You can find your API key at https://platform.openai.com/account/api-keys.",
        "type": "invalid_request_error",
        "param": null,
        "code": "invalid_api_key"
				 
    }
}

When this happens, it throws off the serialization process shifting it towards TEXT encooding instead of JSON encoding.

Exception or Stack Trace

Caused by: java.lang.IllegalStateException: Unsupported text Content-Type Type: class java.lang.Object
	at com.azure.core.util.serializer.JacksonAdapter.deserializeText(JacksonAdapter.java:452)
	at com.azure.core.util.serializer.JacksonAdapter.lambda$deserialize$9(JacksonAdapter.java:353)
	at com.azure.core.util.serializer.JacksonAdapter.useAccessHelper(JacksonAdapter.java:488)
	at com.azure.core.util.serializer.JacksonAdapter.deserialize(JacksonAdapter.java:346)
	at com.azure.core.implementation.serializer.HttpResponseBodyDecoder.deserialize(HttpResponseBodyDecoder.java:176)
	at com.azure.core.implementation.serializer.HttpResponseBodyDecoder.deserializeBody(HttpResponseBodyDecoder.java:150)
	at com.azure.core.implementation.serializer.HttpResponseBodyDecoder.decodeByteArray(HttpResponseBodyDecoder.java:67)
	at com.azure.core.implementation.serializer.HttpResponseDecoder$HttpDecodedResponse.getDecodedBody(HttpResponseDecoder.java:93)
	at com.azure.core.implementation.http.rest.SyncRestProxy.ensureExpectedStatus(SyncRestProxy.java:131)
	at com.azure.core.implementation.http.rest.SyncRestProxy.handleRestReturnType(SyncRestProxy.java:211)
	at com.azure.core.implementation.http.rest.SyncRestProxy.invoke(SyncRestProxy.java:86)
	at com.azure.core.implementation.http.rest.RestProxyBase.invoke(RestProxyBase.java:124)
	at com.azure.core.http.rest.RestProxy.invoke(RestProxy.java:95)
	at jdk.proxy2/jdk.proxy2.$Proxy178.getChatCompletionsSync(Unknown Source)
	at com.azure.ai.openai.implementation.NonAzureOpenAIClientImpl.getChatCompletionsWithResponse(NonAzureOpenAIClientImpl.java:994)
	at com.azure.ai.openai.OpenAIClient.getChatCompletionsWithResponse(OpenAIClient.java:348)
	at com.azure.ai.openai.OpenAIClient.getChatCompletions(OpenAIClient.java:760)

This leads to the Azure OpenAI library to sometimes throw ClientAuthenticationException and some other times a generic HttpResponseException.

To Reproduce
Try to get ChatCompletions for OpenAI multiple times in a row, with an invalid API key, until OpenAI responds (occasionally) with Content-Type: text/plain.

Code Snippet
Set invalid API key as property:
openai.connector.api-key=an-invalid-key

Try to invoke OpenAI via the Azure OpenAI SDK e.g.: with Spring Azure OpenAI:

// assuming a valid AzureOpenAiChatModel bean
azureOpenAiChatModel.call(new Prompt(...));

Expected behavior

The Azure OpenAI library should consistently throw a ClientAuthenticationException in case of a 401 HTTP response.

Setup (please complete the following information):

• OS: Windows 11 / Linux / irrelevant
• IDE: IntelliJ
• Library/Libraries: com.azure/azure-ai-openai/1.0.0-beta.16
• Java version: 21
• App Server/Environment: Tomcat
• Frameworks: Spring Boot

Information Checklist
Kindly make sure that you have added all the following information above and checkoff the required fields otherwise we will treat the issuer as an incomplete report

• Bug Description Added
• Repro Steps Added
• Setup information Added

[samvaity]

@dsibilio Thanks for reporting the issue. @jpalvarezl Could you please take a look and confirm the bug, thanks!