Bug Report Checklist
Description
When a spec contains a path-item operation the parser does not recognize (e.g. the OpenAPI 3.2 / RFC 10008 query method on an openapi: 3.1.0 document) and generation is run with --skip-validate-spec, the operation is silently omitted from the generated client:
- Exit code is
0 and the success banner is printed.
- The generated
api.ts simply lacks the operation (queryTasks below) — no generation-time warning that an operation was skipped.
- The only trace is the generic startup WARN (
There were issues with the specification, but validation has been explicitly disabled), which does not say that code will be missing.
In CI pipelines that use --skip-validate-spec (commonly enabled to tolerate 3.1 nuances), this produces clients that are missing endpoints with no signal. Without the flag, validation correctly fails hard — that path is fine.
Likely mechanism: swagger-parser's PathItem model has fixed operation fields, so the unknown key is dropped at parse time and the generator never sees it — but from a user's perspective the generator is the tool reporting success.
Expected: either (a) a generation-time WARN/ERROR such as skipping unrecognized operation 'query' at path '/tasks', or (b) a non-zero exit / hard failure even under --skip-validate-spec when a path-item member that looks like an operation is dropped.
Related: #22728 (OpenAPI 3.2 support — a 3.2.0 document currently NPEs: Cannot invoke "io.swagger.v3.oas.models.OpenAPI.getExtensions()" because "openAPI" is null, since swagger-parser returns null; a clean error message for unsupported spec versions would also help), swagger-api/swagger-parser#2248.
openapi-generator version
7.14.0 (via @openapitools/openapi-generator-cli). Not a regression as far as I know.
OpenAPI declaration file content
{
"openapi": "3.1.0",
"info": {"title": "QueryTest", "version": "1.0.0"},
"paths": {
"/tasks": {
"get": {
"operationId": "getTasks",
"responses": {"200": {"description": "ok", "content": {"application/json": {"schema": {"$ref": "#/components/schemas/TasksResponse"}}}}}
},
"query": {
"operationId": "queryTasks",
"requestBody": {"required": true, "content": {"application/json": {"schema": {"$ref": "#/components/schemas/TaskFilter"}}}},
"responses": {"200": {"description": "ok", "content": {"application/json": {"schema": {"$ref": "#/components/schemas/TasksResponse"}}}}}
}
}
},
"components": {"schemas": {
"TaskFilter": {"type": "object", "properties": {"status": {"type": "string"}}},
"TasksResponse": {"type": "object", "properties": {"total_count": {"type": "integer"}}}
}}
}
Generation Details
openapi-generator-cli generate -g typescript-axios --skip-validate-spec -i spec.json -o ./out
Steps to reproduce
- Save the spec above as
spec.json.
- Run the command above.
- Observe: exit 0, success output, but
out/api.ts contains only getTasks — queryTasks is absent, and no warning mentions it was skipped.
Suggest a fix
After parsing, diff the raw path-item keys in the source document against the operations present in the parsed PathItem; log an explicit warning (or fail) for any member that was dropped. This keeps --skip-validate-spec usable while making missing-endpoint outcomes visible.
Bug Report Checklist
Description
When a spec contains a path-item operation the parser does not recognize (e.g. the OpenAPI 3.2 / RFC 10008
querymethod on anopenapi: 3.1.0document) and generation is run with--skip-validate-spec, the operation is silently omitted from the generated client:0and the success banner is printed.api.tssimply lacks the operation (queryTasksbelow) — no generation-time warning that an operation was skipped.There were issues with the specification, but validation has been explicitly disabled), which does not say that code will be missing.In CI pipelines that use
--skip-validate-spec(commonly enabled to tolerate 3.1 nuances), this produces clients that are missing endpoints with no signal. Without the flag, validation correctly fails hard — that path is fine.Likely mechanism: swagger-parser's
PathItemmodel has fixed operation fields, so the unknown key is dropped at parse time and the generator never sees it — but from a user's perspective the generator is the tool reporting success.Expected: either (a) a generation-time
WARN/ERRORsuch asskipping unrecognized operation 'query' at path '/tasks', or (b) a non-zero exit / hard failure even under--skip-validate-specwhen a path-item member that looks like an operation is dropped.Related: #22728 (OpenAPI 3.2 support — a
3.2.0document currently NPEs:Cannot invoke "io.swagger.v3.oas.models.OpenAPI.getExtensions()" because "openAPI" is null, since swagger-parser returns null; a clean error message for unsupported spec versions would also help), swagger-api/swagger-parser#2248.openapi-generator version
7.14.0 (via
@openapitools/openapi-generator-cli). Not a regression as far as I know.OpenAPI declaration file content
{ "openapi": "3.1.0", "info": {"title": "QueryTest", "version": "1.0.0"}, "paths": { "/tasks": { "get": { "operationId": "getTasks", "responses": {"200": {"description": "ok", "content": {"application/json": {"schema": {"$ref": "#/components/schemas/TasksResponse"}}}}} }, "query": { "operationId": "queryTasks", "requestBody": {"required": true, "content": {"application/json": {"schema": {"$ref": "#/components/schemas/TaskFilter"}}}}, "responses": {"200": {"description": "ok", "content": {"application/json": {"schema": {"$ref": "#/components/schemas/TasksResponse"}}}}} } } }, "components": {"schemas": { "TaskFilter": {"type": "object", "properties": {"status": {"type": "string"}}}, "TasksResponse": {"type": "object", "properties": {"total_count": {"type": "integer"}}} }} }Generation Details
Steps to reproduce
spec.json.out/api.tscontains onlygetTasks—queryTasksis absent, and no warning mentions it was skipped.Suggest a fix
After parsing, diff the raw path-item keys in the source document against the operations present in the parsed
PathItem; log an explicit warning (or fail) for any member that was dropped. This keeps--skip-validate-specusable while making missing-endpoint outcomes visible.