pb33f / libopenapi

libopenapi is a fully featured, high performance OpenAPI 3.1, 3.0 and Swagger parser, library, validator and toolkit for golang applications.
https://pb33f.io/libopenapi/
Other
487 stars 64 forks source link

Invalid JSON/YAML gets ignored when a document is opened #355

Open inFocus7 opened 5 days ago

inFocus7 commented 5 days ago

Issue

When opening a document with invalid spec, during the decoding of a document regardless of byassing 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

inFocus7 commented 5 days ago

I can also pick this up if it's okay. I have a branch in progress here https://github.com/pb33f/libopenapi/compare/main...inFocus7:libopenapi:355/fix-bad-yaml-not-being-errored-correctly?expand=1. Just need to clean up test naming, and discuss/figure out which path to take (w.r.t. bypass also used to catch decoding errors, or always do so, or add another field to set for this error checking to affect less people)