spec-compliant response codes
Nobody has claimed this yet.
- Dominant language
- TypeScript
- Stars
- 1.5k
- Forks
- 228
- Avg merge
- 1d 14h
- Merged PRs (30d)
- 48
Description
Describe the bug
This excerpt is incorrect but the lint tool doesn't catch that the 200 needs to be a string '200' and the yaml parses it into a number:
paths:
/foo:
get:
responses:
200:
Quoting the spec:
This field MUST be enclosed in quotation marks (for example, “200”) for compatibility between JSON and YAML.
To Reproduce
Steps to reproduce the behavior:
- Given any valid OpenAPI in YAML format with at least one numeric response code (not 2XX for example).
- Run lint
- See that the issue is not caught.
Expected behavior
- Lint should identify the error.
- Maybe we should have a decorator to correct the error.
Logs
n/a
OpenAPI description
3.0/3.1
Redocly Version(s)
1.0-1.5
Node.js Version(s)
18
Additional context
Inspired by #1331
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by running the lint tool against the YAML example with a numeric response code, using an OpenAPI 3.0 or 3.1 document. Trace the response-code linting entry point and add coverage showing that numeric codes are reported, including the non-2XX case. Done means lint identifies the invalid numeric key consistently.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- node.js, openapi, typescript
- Domain
- api, tooling
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 45/100