{"record":{"id":"3d512d3d3911f981","repo":"openai/openai-python","slug":"could-not-resolve-inner-type-variable-at-index-in","errorCode":null,"errorMessage":"Could not resolve inner type variable at index {index} for {typ}","messagePattern":"Could not resolve inner type variable at index (.+?) for (.+?)","errorType":"exception","errorClass":"RuntimeError","httpStatus":null,"severity":"error","filePath":"src/openai/_utils/_typing.py","lineNumber":156,"sourceCode":"                \"This should never happen;\\n\"\n                f\"Does {cls} inherit from one of {generic_bases} ?\"\n            )\n\n        extracted = extract_type_arg(target_base_class, index)\n        if is_typevar(extracted):\n            # If the extracted type argument is itself a type variable\n            # then that means the subclass itself is generic, so we have\n            # to resolve the type argument from the class itself, not\n            # the base class.\n            #\n            # Note: if there is more than 1 type argument, the subclass could\n            # change the ordering of the type arguments, this is not currently\n            # supported.\n            return extract_type_arg(typ, index)\n\n        return extracted\n\n    raise RuntimeError(failure_message or f\"Could not resolve inner type variable at index {index} for {typ}\")\n","sourceCodeStart":138,"sourceCodeEnd":157,"githubUrl":"https://github.com/openai/openai-python/blob/9917c6e28e66e90e1227b3d223c06a8c5441515a/src/openai/_utils/_typing.py#L138-L157","documentation":"extract_type_var_from_base resolves the type argument filling a TypeVar in a generic base class (used to infer response types from isomorphic/generic aliases). If the concrete type does not carry the metadata needed to resolve the TypeVar at the requested index — e.g. the class is generic in a different order, is a non-generic subclass, or typing internals do not expose __orig_bases__/args — it raises this RuntimeError. It is essentially an internal typing-inference failure, most commonly seen in tests of the util itself or in exotic generic hierarchies passed to type-inference helpers.","triggerScenarios":"Calling extract_type_var_from_base on a class whose generic base either lacks the TypeVar at that index or reorders type arguments in an unsupported way; subclasses that parameterize generics in a different order than declared; passing a plain (non-generic) class.","commonSituations":"Building custom generic response wrappers around SDK models; refactoring shared generic base classes and changing TypeVar ordering; SDK upgrades that change internal response typing.","solutions":["Match the TypeVar order of the base class exactly when subclassing generic bases","Use typing.TypeVar with the same variance/position; avoid reordering type arguments in subclasses","If you control the helper, use explicit type annotations instead of runtime inference","Pin or align with the SDK version whose generic layout your code was written against"],"exampleFix":"# before\nclass Wrapper(MyBase[B, A]): ...  # A/B order swapped vs base\n\n# after\nclass Wrapper(MyBase[A, B]): ...  # same order as MyBase's declaration","handlingStrategy":"validation","validationCode":"from openai._utils import extract_type_var_from_base\ntry:\n    extract_type_var_from_base(cls, TypeVar(\"T\"))\nexcept RuntimeError:\n    use_explicit_annotation = True","typeGuard":null,"tryCatchPattern":"try:\n    extract_type_var_from_base(cls, TV, index=0)\nexcept RuntimeError:\n    typ = explicit_type_map.get(cls, fallback)","preventionTips":["Keep TypeVar order aligned with base class","Prefer explicit annotations over runtime inference","Don't depend on private typing helpers in product code"],"tags":["typing","generics","typevar","runtimeerror"],"backgroundTag":"generic-type-inference-failed","analyzedSha":"9917c6e28e66e90e1227b3d223c06a8c5441515a","analyzedAt":"2026-08-28T11:46:34.183Z","schemaVersion":2},"datasetVersion":"2026-08-28T16:17:29.566Z"}