Schema Function Not Working with @key

[dillonredding]

Describe the bug

The schema function doesn't appear to work when field is '@key'. Here's the rule I'm trying to create:

  response-code-type:
    message: Response codes must be strings
    recommended: true
    given: $.paths.*.*.responses
    then:
      field: '@key'
      function: schema
      functionOptions:
        schema:
          type: string

To Reproduce

Given this OpenAPI document

openapi: 3.0.2
info:
  title: Test Spec
  version: 0.0.0
paths:
  /foo:
    get:
      operationId: get-foo
      responses:
        200:
          description: ''

Run this CLI command

spectral lint test-spec.yaml -r my-rules.yaml

Expected behavior

The lint output should contain the following:

 9:17  warning  response-code-type    Response codes must be strings

It might be worth noting that if the rule is changed so that type is number or integer, the rule is triggered.

Environment

• Library version: 4.2.0
• OS: Windows 10

[P0lip]

@dillonredding
I confirm the issue exists. Unfortunately, the potential fix may turn out to be fairly complex given how Spectral works.
Long story short - Spectral uses JS object literal to represent the parsed content.
This is obviously very tricky when it comes to YAML, since YAML is perfectly fine with other primitive values for mapping's keys, i.e. numbers or nulls... not to mention a sequence or a map are valid keys too. JS object literal, on the other hand, can take only 2 types as a key, those are string and symbols (irrelevant in our case).
In this particular scenario, we could fall back to AST and simply make a lookup to see whether it's a string or number or any other type, but unluckily for us this won't solve the underlying issue and hence won't cover other potential spots.

[dillonredding]

@P0lip, thanks for looking at this.

I'm not familiar with the implementation, but could you maybe determine the strategy for using the JS object or the AST based on particular criteria? That way you could add to the criteria as other scenarios pop up.

[P0lip]

@dillonredding
This one will be addressed as well, but in a slightly different manner.
Spectral will warn you about property keys that are not JSON compliant (are no strings in other words).
I hope that will do the trick for you.

[dillonredding]

@P0lip
That's great! So, no custom rule needed?

[P0lip]

@dillonredding no rule will be needed. Each property key that could not be used in JSON will be reported automatically by Spectral