fix(responses): guard parser/output_text when response.output is null

[jackpalm88]

Fix parse_response crash when response.output is None

Summary

This patch hardens the OpenAI Python SDK Responses parsing path against output=None payloads.

Observed failure (openai==2.33.0):

• openai/lib/_parsing/_responses.py iterates response.output unconditionally.
• If a Responses backend returns output: null, parser raises:
  • TypeError: 'NoneType' object is not iterable

Patch behavior:

• Treat response.output is None as an empty list in parser loop.
• Apply same guard in Response.output_text property for consistency.

Why

In rare edge cases, a Responses payload may contain output: null; the SDK should handle this defensively.

Changes

1. src/openai/lib/_parsing/_responses.py

- for output in response.output:
+ for output in (response.output or []):

2. src/openai/types/responses/response.py

- for output in self.output:
+ for output in (self.output or []):

Expected result

• parse_response(...) no longer crashes when response.output is None.
• Parsed response behavior is equivalent to an empty output list.
• Response.output_text returns "" instead of crashing when self.output is None.

Suggested tests

• Add regression test where Response.model_construct(..., output=None) is passed to parse_response.
• Assert parsed response returns output=[].
• Assert Response(..., output=None).output_text == "".

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 946947ce15

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Make output nullable for strict validation

When the API returns output: null and the client is configured with _strict_response_validation=True, this guard is never reached: _process_response_data calls validate_type() before constructing the Response, and Response.output is still declared as List[ResponseOutputItem], so Pydantic rejects None up front. This means strict-validation users still get an APIResponseValidationError for the null-output response this change is trying to tolerate; the field type needs to allow None as well as the runtime guard.

Useful? React with 👍 / 👎.

[jackpalm88]

Happy to adjust the regression tests if maintainers prefer a different test location or setup.