-
-
Notifications
You must be signed in to change notification settings - Fork 89
Description
Issue
When opening a document with invalid spec, during the decoding of a document regardless of bypass
ing the document check, we ignore any errors that come up from decoding (ex. _ = parsedNode.Decode(&jsonSpec)
). parsing code re-used
Expected Behavior
If we set bypass=false
(or some new configuration, if preferred), we should not ignore any errors that happen during decoding.
Reproduction
I linked a branch in Extra Information, but the example spec used for this is:
openapi: "3.0.1"
info:
version: 1.0.0
description: This is a sample server Petstore server.
title: Swagger Petstore
license:
name: MIT
servers:
- url: http://petstore.swagger.io/v1
paths:
/pets:
get:
summary: List all pets
operationId: listPets
tags:
- pets
parameters:
- name: limit
in: query
description: How many items to return at one time (max 100)
required: false
schema:
type: integer
maximum: 100
format: int32
responses:
'200':
description: A paged array of pets
headers:
x-next:
description: A link to the next page of responses
schema:
type: string
content:
application/json:
schema:
$ref: "#/components/schemas/Pets"
default:
description: unexpected error
content:
application/json:
schema:
$ref: "#/components/schemas/Error"
post:
summary: Create a pet
operationId: createPets
tags:
- pets
requestBody:
content:
application/json:
schema:
$ref: '#/components/schemas/Pet'
required: true
responses:
'201':
description: Null response
default:
description: unexpected error
content:
application/json:
schema:
$ref: "#/components/schemas/Error"
/pets/{petId}:
get:
summary: Info for a specific pet
operationId: showPetById
tags:
- pets
parameters:
- name: petId
in: path
required: true
description: The id of the pet to retrieve
schema:
type: string
responses:
'200':
description: Expected response to a valid request
content:
application/json:
schema:
$ref: "#/components/schemas/Pet"
default:
description: unexpected error
content:
application/json:
schema:
$ref: "#/components/schemas/Error"
components:
schemas:
Pet:
type: object
required:
- id
- name
properties:
id:
type: integer
format: int64
name:
type: string
tag:
type: string
Pets:
type: array
maxItems: 100
items:
$ref: "#/components/schemas/Pet"
Error:
type: object
required:
- code
- message
properties:
code:
type: integer
format: int32
message:
type: string
As you can see, the doc has a malindented second path. This should result in an error during decoding - which it does, but it is dropped (_
). Technically the get(?) operation is set twice, since the second path + its operation is just treated as values for the first path, which is why this is a JSON/YAML issue.
Side Note: If you change the second path's operation to something else (put), then it technically would be valid JSON/YAML and would decode properly. At this point, the API doc would be invalid; I already tested that it results in an error through libopenapi-validator
, which is good.
Extra Information
- Originally brought up here, until I narrowed down this issue: Schema validation passes (no errors) on invalid api doc libopenapi-validator#102
- I have a branch in
libopenapi-validator
with the example doc used to reproduce this (error being ignored): https://github.com/pb33f/libopenapi-validator/compare/main...inFocus7:libopenapi-validator:102/fix-malindented-path-validation?expand=1 - Posting the above example in the swagger editor (unsure about
next
version) results in the error we'd expect during decoding.