Python: [Bug]: OpenAIChatCompletionClient fails with 'str' object has no attribute 'system_fingerprint' when provider returns non-OpenAI conformant response

[Shaik-Vaheed-UP]

Description

What happened?

If the OpenAI Chat Completions provider returns a response body that is a plain string (rather than a ChatCompletion object, as expected by the framework client), the following stack trace will result:

Exception: ChatClientException: ("<class 'agent_framework_openai._chat_completion_client.OpenAIChatCompletionClient'> service failed to complete the prompt: 'str' object has no attribute 'system_fingerprint'", AttributeError("'str' object has no attribute 'system_fingerprint'"))
  ...
  File "agent_framework_openai/_chat_completion_client.py", line 687, in _parse_response_from_openai
    response_metadata = self._get_metadata_from_chat_response(response)
  File "agent_framework_openai/_chat_completion_client.py", line 791, in _get_metadata_from_chat_response
    "system_fingerprint": response.system_fingerprint,
AttributeError: 'str' object has no attribute 'system_fingerprint'

What did you expect to happen?

A robust error explaining that the backend provider returned an invalid response, instead of an internal AttributeError. For OpenAI-incompatible provider responses, the client should surface an actionable error, not crash.

Steps to reproduce the issue

1. Point agent-framework Python clients (OpenAIChatCompletionClient) to an OpenAI-compatible proxy/gateway or a backend that occasionally returns payloads that are not strictly compliant with OpenAI's response schema (such as returning plain text for errors, HTML error pages, or unwrapped response bodies).
2. Cause the provider to return a plain string or body that cannot be decoded into a ChatCompletion object.
3. Submit a prompt to the agent, or cause the agent to create a chat completion.
4. The client will raise AttributeError as described above.

Remediation suggestion

Add a defensive type check or a getattr guard for system_fingerprint in _get_metadata_from_chat_response, and surface non-object provider responses as clear errors (with payload included for debugging).

This pattern was already used for other non-conformant response fields (see code handling streaming "delta": null, etc.).

---

Note: No existing issues matched this pattern in this repo as of June 2026. Let me know if more info is needed or for a PR.

Code Sample

Using the OpenAIChatCompletionClient against a non-OpenAI backend (proxy/gateway/custom deploy) that sometimes returns a plain string:


from agent_framework_openai import OpenAIChatCompletionClient
client = OpenAIChatCompletionClient(base_url="https://mynonopenai-endpoint/v1")
# Simulate a non-conformant backend response
response = await client.get_response([{"role": "user", "content": "hi"}])
# The request triggers the above error.

Error Messages / Stack Traces

Exception: ChatClientException: ("<class 'agent_framework_openai._chat_completion_client.OpenAIChatCompletionClient'> service failed to complete the prompt: 'str' object has no attribute 'system_fingerprint'", AttributeError("'str' object has no attribute 'system_fingerprint'"))
File "/home/site/wwwroot/.python_packages/lib/site-packages/agent_framework_openai/_chat_completion_client.py", line 554, in _get_response
return self._parse_response_from_openai( ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/site/wwwroot/.python_packages/lib/site-packages/agent_framework_openai/_chat_completion_client.py", line 687, in _parse_response_from_openai
response_metadata = self._get_metadata_from_chat_response(response)
File "/home/site/wwwroot/.python_packages/lib/site-packages/agent_framework_openai/_chat_completion_client.py", line 791, in _get_metadata_from_chat_response
"system_fingerprint": response.system_fingerprint,
AttributeError: 'str' object has no attribute 'system_fingerprint'

Package Versions

agent-framework-openai: (latest main as of June 2026)
agent-framework-core: (latest main as of June 2026)

Python Version

Python 3.12

Additional Context

Can provide raw response if needed. Problem is easy to repro against OpenAI-compatible backends that serve non-spec responses (see discussion above).