BUG: 'Enum values must be snake case' on enums like '400', '500'
maxprofit opened this issue · 4 comments
version: 1.18.0
IBM OpenAPI Validator (validator: 1.18.0), @Copyright IBM Corporation 2017, 2024.
Validation Results for api/openapi.yaml:
Errors:
Message : Enum values must be snake case
Rule : ibm-enum-casing-convention
Path : components.schemas.ErrorInner.properties.code.enum.0
Line : 413
Message : Enum values must be snake case
Rule : ibm-enum-casing-convention
Path : components.schemas.ErrorInner.properties.code.enum.1
Line : 414
The lines in question:
ErrorInner:
properties:
message:
type: string
code:
description: The HTTP status code
type: string
enum:
- '400'
- '500'
more_info:
type: string
I'm following the way the validator is telling me to do HTTP errors and then I get this error saying I need to do snake case on number strings? Weird since there are literally no word characters there?
Spectral and Redocly have no issues with my openapi.yaml, as a reference.
I think the root of the issue is the fact that the "code" value is not meant to be the HTTP
status code, which is intended to be captured at the error container level, rather than the error model level. See our API Handbook for more info. The documentation for the "code" value says:
This field MUST contain a snake case string succinctly identifying the problem.
We could ostensibly rethink if we want to allow numbers at the beginning of a valid snake-case string but in this case, I think we're actually seeing intended behavior.
You're certainly correct that I wasn't doing it right for the error type. I've corrected that now, thanks!
I made another enum in a different place and the values still couldn't be represented as strings representing integers though, from what I know about the spec it allows this, so this is still a bug?
components:
schemas:
TestSchema:
type: string
enum:
- '400'
- '500'
IBM OpenAPI Validator (validator: 1.18.0), @Copyright IBM Corporation 2017, 2024.
Validation Results for api/openapi.yaml:
Errors:
Message : Enum values must be snake case
Rule : ibm-enum-casing-convention
Path : components.schemas.TestSchema.enum.0
Line : 256
Message : Enum values must be snake case
Rule : ibm-enum-casing-convention
Path : components.schemas.TestSchema.enum.1
Line : 257
I've corrected that now, thanks!
No problem!
I made another enum in a different place and the values still couldn't be represented as strings representing integers though, from what I know about the spec it allows this, so this is still a bug?
The "rules" of casing conventions can be inconsistent and hard to nail down really solid definitions for. That said, I feel I most often see definitions for "snake case" that don't allow a number to be at the start of the string. We actually use Spectral's casing function to perform this check in the validator, so we aren't even taking an opinionated stand on this in our logic. We're treating their definition as a standard.
Fair enough, makes sense for things like openapi-generator too for when it generates enum values! Feel free to close this!