OpenAPITools/openapi-generator · error · RuntimeException
Error! Codegen Parameter not yet supported in getPydanticTyp
Error message
Error! Codegen Parameter not yet supported in getPydanticType: %s
What it means
In AbstractPythonCodegen's getPydanticType(CodegenParameter, ...), a parameter is expected to have either a resolved dataType (the normal path for typed parameters) or request-body style content. A parameter with neither falls through to this RuntimeException — the generator has no pydantic type mapping for that parameter at all.
Source
Thrown at modules/openapi-generator/src/main/java/org/openapitools/codegen/languages/AbstractPythonCodegen.java:2364
if (result == null) {
if (!cp.isPrimitiveType) {
// add model prefix
hasModelsToImport = true;
modelImports.add(cp.getDataType());
exampleImports.add(cp.getDataType());
result = new PythonType(cp.getDataType());
} else if (cp.getContent() != null) {
LinkedHashMap<String, CodegenMediaType> contents = cp.getContent();
for (String key : contents.keySet()) {
CodegenMediaType cmt = contents.get(key);
// TODO process the first one only at the moment
if (cmt != null)
// TODO: don't loop back to the deprecated getPydanticType method
return getPydanticType(cmt.getSchema(), modelImports, exampleImports, postponedModelImports, postponedExampleImports, moduleImports, classname);
}
throw new RuntimeException("Error! Failed to process getPydanticType when getting the content: " + cp);
} else {
throw new RuntimeException("Error! Codegen Parameter not yet supported in getPydanticType: " + cp);
}
}
return result;
}
private String finalizeType(CodegenParameter cp, PythonType pt) {
if (!cp.required || cp.isNullable) {
moduleImports.add(TYPING, "Optional");
PythonType opt = new PythonType("Optional");
opt.addTypeParam(pt);
pt = opt;
}
if (!StringUtils.isEmpty(cp.description)) { // has description
pt.annotate("description", cp.description);
}
View on GitHub (pinned to fcec517be3)
Solutions
- Add an explicit schema to the failing parameter, e.g. schema: { type: string }
- Resolve or inline the parameter's $ref so it carries a real schema
- Run a Spectral/swagger-cli validation pass — parameters without schemas are flagged before generation ever runs
Example fix
# before
parameters:
- name: q
in: query
# after
parameters:
- name: q
in: query
schema:
type: string Defensive patterns
Strategy: validation
Validate before calling
// JS: every operation parameter must carry a schema (or valid $ref to one)
for (const item of Object.values(spec.paths || {})) {
for (const op of Object.values(item)) {
for (const p of (op && op.parameters) || []) {
if (!p.schema && !p.$ref) fail(`parameter '${p.name}' has no schema`);
}
}
} Try / catch
try { generator.generate(); } catch (RuntimeException e) { if (String.valueOf(e.getMessage()).contains("Codegen Parameter not yet supported")) { /* message prints the parameter: add its missing schema */ } throw e; } Prevention
- Lint specs with Spectral's oas3 rules — schema-less parameters are caught pre-generation
- Inline or resolve parameter $refs and re-validate after refactors
- Prefer a single parameter component style across the whole spec
When it happens
Trigger: A query/header/path parameter with no usable schema so dataType stays unset, e.g. { name: q, in: query } with the schema block missing, or a schema whose type the mapper leaves unresolved, or a $ref that resolves to an object without a schema.
Common situations: Typos that drop the schema: block; spec converters/prototools emitting parameters without schemas; lenient OpenAPI 3.1 parsing letting incomplete parameters through to generation.
Related errors
- Error! Codegen Parameter not yet supported in getPydanticTyp
- Error! Failed to process getPydanticType when getting the co
- Please report the issue as the parameter name cannot be null
- Empty method name (operationId) not allowed
- Error! Failed to process getPydanticType when getting the co
AI-assisted analysis of OpenAPITools/openapi-generator@fcec517be3 (2026-08-22).
Data as JSON: /api/errors/f254e0a5d4df64e0.
Report an issue: GitHub.