[Question] Configurable rule to check any schemas within responses

[samanthawritescode]

Apologies if there was a better place for this.

I'm trying to write a rule that doesn't allow the enum property within API responses, but does allow it within API requests.

Either of these options definitely work if I wanted to disallow the enum property everywhere:

rule/no-enums:
  subject:
    type: Schema
    property: enum
  assertions:
    defined: false

rule/no-enums:
  subject:
    type: any
    property: enum
  assertions:
    defined: false

But I'm completely struggling to write something that only targets Schema nodes referenced from anything under a Response node. Among other things, I've tried:

rule/no-enums-in-responses:
  where:
    - subject:
        type: Response
      assertions:
        defined: true
  subject:
    type: Schema
    property: enum
  assertions:
    defined: false

and even enumerating all the nodes between Response and a Schema:

rule/no-enums-in-responses:
  where:
    - subject:
        type: Response
      assertions:
        defined: true
    - subject:
        type: MediaTypesMap
      assertions:
        defined: true
    - subject:
        type: MediaType
      assertions:
        defined: true
  subject:
    type: Schema
    property: enum
  assertions:
    defined: false

I've also tried things like:

rule/no-enums-in-responses:
  where:
    - subject:
        type: Response
        filterInParentKeys:
          - '200'
      assertions:
        defined: true
  subject:
    type: Schema
  assertions:
    disallowed:
      - enum

I'm at a loss. I'm even trying to run these on a bundled version of my spec so there are no references to possibly mess things up. Thanks in advance for any help!

[tatomyr]

This is interesting.

Schema could contain other schemas, and in your examples, you might be referring to a nested schema.
If you aren't using the where clause, it propagates further down the nested schemas.
The problem here is that whenever you use the where, it stops at the first Schema level it encounters after Response (which, in your case, doesn't contain an enum). The behaviour originates from the behaviour of nested visitors in Redocly CLI.

I don't think we will change the behaviour as it will change how the existing rules work (it might impact other users' rules). I have to think about this more.

As a workaround, you can try writing a custom rule through a plugin for that case. However, it requires some knowledge of JavaScript. I'm not sure it will be easy because the default behaviour will likely be the same because of how the nested visitors work.

A different workaround might be adding another level of the where funnel:

  rule/no-enums-in-responses:
    where:
      - subject:
          type: Response
        assertions:
          defined: true
      - subject: 
          type: SchemaProperties # <-- this ensures we bypass the first level of Schema and check only on the 2nd level 
        assertions: 
          defined: true
        
    subject:
      type: Schema
    assertions:
      disallowed: 
        -  enum

Please keep in mind that the rule will only check for enums in the first Schema inside of the first SchemaProperties.

Let me know if that helps.

[samanthawritescode]

Hey, thank you for the response!

I'm getting by with just blocking enum everywhere and adding exceptions for enums in requests via the redocly ignore file. And I think, for now, it's enough to know that this isn't possible really out of the box.

FWIW my motivation here is that enums in responses are risky from a breaking-changes perspective, but they're not as risky when they're in requests (adding to an enum is a breaking change in a response, but adding to a enum in a request is not). I would expect that it's not uncommon for APIs to have different expectations for schemas in requests vs. responses.