Skip to content

Responses streaming: response.function_call_arguments.done events lack the required 'name' field, failing strict event-union validation #3472

Description

@mecampbellsoup

Confirm this is an issue with the Python library and not an underlying OpenAI API

  • This is an issue with the Python library (or spec drift between the SDK models and the live API)

Describe the bug

ResponseFunctionCallArgumentsDoneEvent declares name: str as required (both in v2.38.0 and in the current generated model on main), but the live Responses API's streamed response.function_call_arguments.done events do not include a name key.

Observed payload from a streamed responses.create call with function tools (gpt-5.4):

{
  "type": "response.function_call_arguments.done",
  "arguments": "{...}",
  "item_id": "fc_0e7fa7b0f70886a0006a4a7f734bd881929f7d0eae45f46f97",
  "output_index": 2,
  "sequence_number": 10
}

Strict validation of the ResponseStreamEvent union therefore fails on every such event with missing: name (plus the ~100 other enumerated union-member errors). Nothing crashes — construct_type (openai/_models.py:621 → validate_type:843 → _validate_non_model_type:890) tries strict validation inside a try/except and falls back to lenient construction, so the event flows through with name unset — but:

  1. Anyone running pydantic validation instrumentation (e.g. logfire's pydantic plugin) sees a warning with ~101 enumerated errors per function-call round, and
  2. event.name on these events is silently None despite the type declaring str, so type-checked user code reading it is misled.

Since the current main model (Stainless-generated) still requires name, this looks like drift between the OpenAPI spec and the live API rather than a stale pin — either the API should emit name on response.function_call_arguments.done (it's genuinely useful; today one must correlate via item_id back to the output_item.added event to know which function completed), or the model field should be Optional[str].

For prior art on this bug class: #2311 (a mis-mapped streaming event type, since fixed).

To Reproduce

  1. Call client.responses.create(stream=True, tools=[...]) with a prompt that triggers a function call (observed on gpt-5.4).
  2. Validate incoming SSE event dicts strictly against ResponseStreamEvent (or run any pydantic validation instrumentation).
  3. Every response.function_call_arguments.done event fails strict validation with missing: name for ResponseFunctionCallArgumentsDoneEvent.

Code snippets

# The event payload above, validated strictly:
from openai.types.responses import ResponseFunctionCallArgumentsDoneEvent
ResponseFunctionCallArgumentsDoneEvent.model_validate({
    "type": "response.function_call_arguments.done",
    "arguments": "{}",
    "item_id": "fc_x",
    "output_index": 0,
    "sequence_number": 1,
})  # pydantic.ValidationError: name Field required

OS

Linux (Docker)

Python version

Python 3.14.0

Library version

openai 2.38.0 (model on current main also declares name: str required)

Activity

  1. Mahnoor-Zaffar commented on Jul 6, 2026

    @Mahnoor-Zaffar

    Hey, I would love to work on this.
    Can you assign me this issue?

    Thanks

  2. nomiveritas commented on Jul 7, 2026

    @nomiveritas

    From the response.output_item.added event, you store the item_id → name mapping, and then use it for subsequent function_call_arguments.done events. This is a fully API-compatible solution with the current API.

  3. Hughhhhcoder commented on Sep 8, 2026

    @Hughhhhcoder
    Contributor

    This is fixed on current main by #3801 (2a98f6a1dee448c6410531c89c2de0af4383c6a7), which removed the generated name field from the stable and beta response.function_call_arguments.done event models and correlates the function-call item by item_id where the name is needed.

    I re-ran the issue's strict-validation reproduction at current main (be928151): the payload without name now validates successfully as ResponseFunctionCallArgumentsDoneEvent. No release tag currently contains the fixing commit, so this is fixed on main but does not appear to be in a tagged release yet.

  4. markstuart-oai commented on Sep 8, 2026

    @markstuart-oai
    Contributor

    Hi @Hughhhhcoder, this was just released with 3.9.0!

    #3796

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Labels

No labels
No labels

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions