[BUG] Unrecognized path-item operations (e.g. OpenAPI 3.2 'query') are silently dropped from generated code with --skip-validate-spec

Bug Report Checklist

• Have you provided a full/minimal spec to reproduce the issue?
• Have you validated the input using an OpenAPI validator?
• Have you tested with the latest master to confirm the issue still exists?
• Have you searched for related issues/PRs?
• What's the actual output vs expected output?

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

1. Save the spec above as spec.json.
2. Run the command above.
3. 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.

Start with the spec.json reproduction and trace how swagger-parser's PathItem model handles the /tasks path before generation produces out/api.ts. Compare raw path-item keys with parsed operations, then verify that an unrecognized operation produces the proposed warning or failure while recognized operations still generate normally.