OpenAPITools/openapi-generator · error · RuntimeException
Error! Codegen Property not yet supported in getPydanticType
Error message
Error! Codegen Property not yet supported in getPydanticType: {cp} What it means
In AbstractPythonPydanticV1Codegen's getPydanticType for properties, every CodegenProperty must reduce to a Python type through the handled branches (primitives, containers, enums, model refs). A property matching no branch falls through to this RuntimeException — the pydantic-v1 mapper has no type mapping for that property shape yet.
Source
Thrown at modules/openapi-generator/src/main/java/org/openapitools/codegen/languages/AbstractPythonPydanticV1Codegen.java:1596
if (circularImports.get(cp.dataType).contains(classname)) {
hasModelsToImport = true;
postponedModelImports.add(cp.dataType);
postponedExampleImports.add(cp.dataType);
// cp.dataType import map of set contains this model (classname), don't import
LOGGER.debug("Skipped importing {} in {} due to circular import.", cp.dataType, classname);
} else {
// not circular import, so ok to import it
hasModelsToImport = true;
modelImports.add(cp.dataType);
exampleImports.add(cp.dataType);
}
} else {
LOGGER.error("Failed to look up {} from the imports (map of set) of models.", cp.dataType);
}
}
return cp.dataType;
} else {
throw new RuntimeException("Error! Codegen Property not yet supported in getPydanticType: " + cp);
}
}
public void setMapNumberTo(String mapNumberTo) {
if ("Union[StrictFloat, StrictInt]".equals(mapNumberTo)
|| "StrictFloat".equals(mapNumberTo)
|| "float".equals(mapNumberTo)) {
this.mapNumberTo = mapNumberTo;
} else {
throw new IllegalArgumentException("mapNumberTo value must be Union[StrictFloat, StrictInt], StrictStr or float");
}
}
public String toEnumVariableName(String name, String datatype) {
name = name.replace(".", "_DOT_");
if ("int".equals(datatype)) {
return "NUMBER_" + name.replace("-", "MINUS_");View on GitHub (pinned to fcec517be3)
Solutions
- Find the failing property from the CodegenProperty dump and restructure it — hoist composed inner schemas into named components
- Upgrade openapi-generator to the latest release with improved pydantic-v1 coverage
- Still failing, open a GitHub issue with the model snippet — the exception says the case is not yet supported
Example fix
# before
metadata:
type: object
additionalProperties:
oneOf:
- type: string
- type: boolean
# after
metadata:
type: object
additionalProperties:
$ref: '#/components/schemas/MetadataValue' Defensive patterns
Strategy: try-catch
Try / catch
try {
new DefaultGenerator().opts(clientOptInput).generate();
} catch (RuntimeException e) {
if (e.getMessage() != null && e.getMessage().contains("not yet supported in getPydanticType")) {
// CodegenProperty dump in the message names the failing property: hoist/simplify it
throw new BuildFailure("Unsupported pydantic-v1 property: " + e.getMessage(), e);
}
throw e;
} Prevention
- Pin and regularly bump the generator; coverage gaps close over time
- Prefer named component schemas over inline nested compositions
- Smoke-generate in CI with -g python-pydantic-v1 for every spec change
When it happens
Trigger: Generating -g python-pydantic-v1 when a model property uses a combination the mapper does not cover — e.g. maps of composed schemas or other nested constructs, depending on release. The message dumps the full CodegenProperty, identifying the offender.
Common situations: Complex enterprise specs with unusual nesting; running a newer spec against an older pinned generator; migrating from -g python to -g python-pydantic-v1 and hitting v1-specific gaps.
Related errors
- Error! Codegen Property not yet supported in getPydanticType
- property %s in model %s has invalid generated Python field n
- recursionLimit must be an integer, e.g. 2000.
- Could not process model '{name}'.Please make sure that your
- Could not process operation: Tag: {tag} Operation: {oper
AI-assisted analysis of OpenAPITools/openapi-generator@fcec517be3 (2026-08-22).
Data as JSON: /api/errors/7a1f3e6ccc915ec7.
Report an issue: GitHub.