Can't seem to get rid of a response validation error with format: byte, nullable true about openapi_first

[ahx]

I just learned recently that using nullable in OpenAPI 3.0 schemas does not disable other object constraints like "enum" or the like. From the spec:

[…] A true value adds "null" to the allowed type specified by the type keyword, only if type is explicitly defined within the same Schema Object. Other Schema Object constraints retain their defined behavior, and therefore may disallow the use of null as a value. A false value leaves the specified or default type unmodified. The default value is false.

So for example { type: 'string', enum: ['a', 'b'], nullable: true } does not allow null as a value.

[MrBananaLord]

are you using 3.0 or 3.1? because in 3.1 you have new syntax (per migration guide https://www.openapis.org/blog/2021/02/16/migrating-from-openapi-3-0-to-3-1-0):

       sign:
          type: [string, "null"]
          format: byte
          nullable: true
          description: data-URI of the employee signature

[neongrau]

are you using 3.0 or 3.1? because in 3.1 you have new syntax (per migration guide https://www.openapis.org/blog/2021/02/16/migrating-from-openapi-3-0-to-3-1-0):

       sign:

          type: [string, "null"]

          format: byte

          nullable: true

          description: data-URI of the employee signature

Still 3.0 and there it's just terrible. Going to remove the format and go with plain string then.

[neongrau]

interestingly i previously used format: base64which doesn't exist. Yet no validator complains and spectral lintnot even gives a warning.

I just learned recently that using nullable in OpenAPI 3.0 schemas does not disable other object constraints like "enum" or the like. From the spec:

[…] A true value adds "null" to the allowed type specified by the type keyword, only if type is explicitly defined within the same Schema Object. Other Schema Object constraints retain their defined behavior, and therefore may disallow the use of null as a value. A false value leaves the specified or default type unmodified. The default value is false.

So for example { type: 'string', enum: ['a', 'b'], nullable: true } does not allow null as a value.

I know about the enum restriction, which at least allows in 3.1 the means to add null to the enum though 3.0 does not.
Then if making up a format that doubles as being more descriptive goes around this. Then fine for now.
Got to work with the restricted stuff i can generate with rswag until i can replace that with something better.