schema-enum-types (AsyncAPI linter rule)

schema-enum-types

Since 0.9.0 · fixed by --fix

This rule ensures that the values listed in the enum of a schema are allowed by the schema’s type.

Rule Details

An enum value whose type is not allowed by the schema can never be sent or received: a message containing it would fail validation. Such values usually come from a missing or wrong type, or from unquoted YAML values (e.g. yes, 1.0) that are parsed as something other than strings.

The schema-enum-types rule checks every schema of an AsyncAPI document that has an enum list, and reports Enum value type is not in the schema type when one of the values is not allowed by the schema’s type:

strings require string, booleans require boolean, null requires null, arrays require array and objects require object,
integer values require integer or number,
other numeric values require number.

A schema that has an enum but no type is reported as well, since none of its values is allowed by an explicit type.

Configuration

None.

Examples

Good.

asyncapi: 3.0.0
info:
  title: Pet Events
  version: 1.0.0
components:
  schemas:
    PetStatus:
      type: [string, "null"]
      enum: [AVAILABLE, ADOPTED, null]
    Rating:
      type: number
      enum: [1, 2.5, 5]

Bad. The values are integers, but the schema allows only strings.

asyncapi: 3.0.0
info:
  title: Pet Events
  version: 1.0.0
components:
  schemas:
    Priority:
      type: string
      enum: [1, 2, 3]

Automatic fixes

When invoked with --fix, this rule sets the type of a reported schema to the type of its enum values, provided that all values have the same type and the schema has no format. In the “Bad” example above, the type of Priority is changed to integer. Schemas mixing values of different types are not fixed.

When Not to Use It

We recommend to always enable this rule.

Compatibility

This rule is compatible with AsyncAPI 3.x documents. AsyncAPI 2.x documents are rejected by the reader and are not linted.