BUG: IndexError in _transform_recursive when TypedDict field uses bare dict annotation

[devteamaegis]

What breaks

When a TypedDict field is annotated with a bare, unparameterised dict (e.g. metadata: dict instead of metadata: dict[str, str]), calling transform() raises an IndexError.

How to trigger

from typing import TypedDict
from openai._utils._transform import transform

class TestParams(TypedDict, total=False):
    metadata: dict  # bare dict — no type parameters

result = transform({"metadata": {"key": "value"}}, TestParams)

Traceback

File ".../openai/_utils/_transform.py", line 183, in _transform_recursive
    items_type = get_args(stripped_type)[1]
                 ~~~~~~~~~~~~~~~~~~~~~~~^^^
IndexError: tuple index out of range

Root cause

In _transform_recursive (and its async counterpart), the branch that handles origin == dict unconditionally does get_args(stripped_type)[1]. For a bare dict, get_args(dict) returns an empty tuple, so the index access crashes.

Fix

Guard the index access: store args = get_args(stripped_type) and only recurse with args[1] when len(args) >= 2; otherwise fall through and return data unchanged.

[nomiveritas]

Suggested fix

First check that enough type arguments exist before accessing the value type:

args = get_args(stripped_type)

if len(args) >= 2:
items_type = args[1]
return {
key: _transform_recursive(value, annotation=items_type)
for key, value in data.items()
}

return data

This prevents an IndexError because a bare dict produces an empty tuple from get_args(). In that case, the function simply returns the data unchanged.

Respectfully

[nightcityblade]

Hi, I'd like to work on this. I'll submit a PR shortly.

[Xsidz]

Working on this in PR #3625 (same root cause — both fixed together).

[marcuswood-oai]

Thank you for the report and follow-ups. Bare dict annotations have no type arguments, which caused the unchecked lookup to raise IndexError. #3760 now handles them in both sync and async request transformation while retaining nested model serialization.

The merge has resolved and automatically closed this issue. Please use a release containing #3760 when available; the fix is in main and is not included in v3.11.0.