stoplightio / spectral

A flexible JSON/YAML linter for creating automated style guides, with baked in support for OpenAPI v3.1, v3.0, and v2.0 as well as AsyncAPI v2.x.
https://stoplight.io/spectral
Apache License 2.0
2.43k stars 235 forks source link

oas3-schema rule did not show the correct path and line number for response having extra schema with $ref #2507

Open coliu19 opened 1 year ago

coliu19 commented 1 year ago

Describe the bug In an oas3 spec's response schema, I used schema: $ref without content keys etc around which is a oas2 format. Then spectral will raise Property "schema" is not expected to be here which is correct. But it did not show the correct path and line number.

To Reproduce

  1. Given this OpenAPI document 'ref.json':
    {
    "openapi": "3.0.0",
    "info": {
    "version": "1.0",
    "title": "Petstore",
    "license": {
      "name": "MIT"
    }
    },
    "servers": [
    {
      "url": "http://petstore.swagger.io/v1"
    }
    ],
    "tags": [
    {
      "name": "hello",
      "description": "desc"
    }
    ],
    "paths": {
    "/pets/{petId}": {
      "get": {
        "summary": "Info for a specific pet",
        "operationId": "showPetById",
        "tags": [
          "pets"
        ],
        "responses": {
          "200": {
            "description": "Incorrect",
            "schema": {
              "$ref": "#/components/schemas/Pet"
            }
          },
          "202": {
            "description": "Correct",
            "content": {
              "application/json": {
                "schema": {
                  "$ref": "#/components/schemas/Pet"
                }
              }
            }
          }
        }
      }
    }
    },
    "components": {
    "schemas": {
      "Pet": {
        "required": [
          "id",
          "name"
        ],
        "properties": {
          "id": {
            "type": "integer",
            "format": "int64"
          },
          "name": {
            "type": "string"
          }
        }
      }
    }
    }
    }
  2. Given this rule 'validation.js':
import { oas } from '@stoplight/spectral-rulesets';
export default {
  'extends': [
    [
      oas,
      'off',
    ],
  ],
  'rules': {
    'oas3-schema': 'error',
  },
};
  1. Run this CLI command spectral lint -r validation.js ref.json
  2. See error spectral-cli 6.5.1: 52:13 error oas3-schema Property "schema" is not expected to be here. components.schemas.Pet spectral-cli 6.8.0 21:11 error oas3-schema Property "schema" is not expected to be here. paths

Expected behavior The output should be 32:22 error oas3-schema Property "schema" is not expected to be here. paths./pets/{petId}.get.responses[200].schema

Environment (remove any that are not applicable):

Additional context paths./pets/{petId}.get.responses[200] the responses have additional properties "schema", which violates the oas3 schema spec here: https://github.com/OAI/OpenAPI-Specification/blob/main/schemas/v3.0/schema.json#L930.
The correct syntax is actually shown on paths./pets/{petId}.get.responses[202]. oas3-schema rule behaves differently in two spectral versions. Both did not show the correct path and line number.

This is related to "ref" resolve. If I go to node_modules, and add resolved: false to the oas3-schema rule, it will show the correct result.
So the fix may be

  1. override the oas3-schema rule in my own ruleset. Can someone show me how to do this? Did not try out yet.
  2. not resolving the whole spec may introduce other issues, spectral should determine to resolve or not to resolve intelligently. so there should be some enhancements around this code: https://github.com/stoplightio/spectral/blob/develop/packages/core/src/runner/lintNode.ts#L68
derbylock commented 1 year ago

Seems like the same problem as in the #2506

coliu19 commented 1 year ago

Seems like the same problem as in the #2506

Actually not the same.

I first find this issue with spectral-cli 6.5.1, which use spectral-core version of "1.14.1", It wrongly point the error deep into the $ref's inner which actually it has nothing to do with it. The actual error is in additional "schema" key is not allowed.

Then I upgrade spectral-cli to the newest version, which use spectral core 1.18.2, to see if this issue was fixed in the newest version. Happened to see it behave differently by just showing the path, which https://github.com/stoplightio/spectral/issues/2506 was saying.

coliu19 commented 1 year ago

Hi, anything unclear for this issue? I will add if any.