Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Placeholders in paths lead to incorrect path in validation messages #2410

Open
ductaily opened this issue Feb 24, 2023 · 2 comments
Open

Placeholders in paths lead to incorrect path in validation messages #2410

ductaily opened this issue Feb 24, 2023 · 2 comments
Labels

Comments

@ductaily
Copy link

Describe the bug

Given an OAS document with paths defined that contain placeholders in this shape: ('{localId}').
We define a rule that evaluates response objects defined in such paths.

The result of the messages in case if some response object do not adhere to the define rule does not contain the correct path to the response object. Instead, only the paths property is shown in the path of the message.

To Reproduce

Example to run:
https://github.com/ductaily/spectral-odata-placeholder

{
  "openapi": "3.0.2",
  "info": {
    "title": "Service for namespace PetStore",
    "description": "This service is located at [/pet-store/](/pet-store/)",
    "version": "2"
  },
  "paths": {
    "/Dogs('{localId}')": {
      "get": {
        "summary": "Retrieve a single dog.",
        "tags": [
          "Dogs"
        ],
        "responses": {
          "200": {
            "description": "Retrieved dog",
            "content": {
              "application/json": {
                "schema": {
                  "$ref": "#/components/schemas/PetStore.Dogs"
                }
              }
            }
          }
        }
      }
    }
  },
  "components": {
    "schemas": {
      "PetStore.Dogs": {
        "title": "Dog",
        "type": "object",
        "properties": {
          "name": {
            "type": "string",
            "maxLength": 200,
            "nullable": true
          },
          "birthDate": {
            "type": "string",
            "format": "date",
            "example": "2017-04-13",
            "nullable": true
          },
          "id": {
            "type": "string"
          }
        },
        "description": "Test"
      }
    }
  }
}

Rule:

const ruleset = {
  extends: [oas],
  rules: {
    "odata-place-holder": {
      message: "Field `x-custom-extension` missing.",
      severity: DiagnosticSeverity.Error,
      given: '$.paths.*.*.responses[?(@property.match(/^[12]/))].content.application/json[?(@.type == "object")]',
      then: {
        field: "x-custom-extension",
          function: truthy
      }
    }
  }
}

Expected behavior
Expected the message to contain the correct path to the object where the violation of the rule happened.
However, the message only contains path: ["paths"] instead the full path to the object.

Environment (remove any that are not applicable):

  • Library version: 6.6.0
@pavelkornev
Copy link
Contributor

Note: the JSONPath itself seems to be working and the check works, it's only that Spectral returns the wrong path in the response, also wrong line number.

@P0lip
Copy link
Contributor

P0lip commented Feb 24, 2023

I can confirm it's a bug.
Long story short - it's lodash.topath converting $['paths']['/Dogs('{localId}')']['get']['responses'][200]['content']['application/json']['schema'] into

[
  '$',
  'paths',
  "'/Dogs('{localId}')'", // note the extra single quotes here
  'get',
  'responses',
  '200',
  'content',
  'application/json',
  'schema'
]

instead of

[
  '$',
  'paths',
  "/Dogs('{localId}')",
  'get',
  'responses',
  '200',
  'content',
  'application/json',
  'schema'
]

However, to be fair it's worth pointing out that the path provided by jsonpath-plus tho isn't escaped quite correctly since the actual input should like something as follows $['paths']['/Dogs(\'{localId}\')']['get']['responses'][200]['content']`.

@P0lip P0lip added t/bug Something isn't working p/medium labels Feb 24, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

5 participants