Summary
ResponsesRequest declares several fields as optional, but the local Responses API server later treats some of them as concrete values. Explicit JSON null therefore validates and can fail at runtime.
Three concrete paths are affected:
metadata=None validates, then StreamResponsesEvents.__init__() calls request_body.metadata.get(...).
tools=None validates. If instructions is non-empty, the server enters if body.instructions or body.tools: and then iterates for tool in body.tools.
max_output_tokens=None validates, then the generation loop compares len(self.output_tokens) >= self.request_body.max_output_tokens.
The official OpenAI Python Responses request types also expose these parameters as optional, so explicit nullable values are part of the client-side contract rather than malformed Python objects.
Impact
Requests that pass validation can fail later with AttributeError or TypeError instead of being processed with the server's existing defaults/empty values.
Proposed resolution
Normalize the nullable fields at the ResponsesRequest model boundary:
metadata=None -> {}
tools=None -> []
max_output_tokens=None -> DEFAULT_MAX_OUTPUT_TOKENS
This lets the rest of the server keep its existing concrete-value assumptions while preserving accepted nullable request input.
Add model-level regressions for all three explicit-None cases.
Summary
ResponsesRequestdeclares several fields as optional, but the local Responses API server later treats some of them as concrete values. Explicit JSONnulltherefore validates and can fail at runtime.Three concrete paths are affected:
metadata=Nonevalidates, thenStreamResponsesEvents.__init__()callsrequest_body.metadata.get(...).tools=Nonevalidates. Ifinstructionsis non-empty, the server entersif body.instructions or body.tools:and then iteratesfor tool in body.tools.max_output_tokens=Nonevalidates, then the generation loop compareslen(self.output_tokens) >= self.request_body.max_output_tokens.The official OpenAI Python Responses request types also expose these parameters as optional, so explicit nullable values are part of the client-side contract rather than malformed Python objects.
Impact
Requests that pass validation can fail later with
AttributeErrororTypeErrorinstead of being processed with the server's existing defaults/empty values.Proposed resolution
Normalize the nullable fields at the
ResponsesRequestmodel boundary:metadata=None->{}tools=None->[]max_output_tokens=None->DEFAULT_MAX_OUTPUT_TOKENSThis lets the rest of the server keep its existing concrete-value assumptions while preserving accepted nullable request input.
Add model-level regressions for all three explicit-
Nonecases.