Generic error when linting schema

[lordnelson]

I am trying to lint a schema that may have some issues but is currently successfully having code generated from it. When I try to run vacuum I get the following generic error:

Location        | Severity | Message                               | Rule        | Category | Path
openapi.yml:0:0 | error    | schema invalid: got null, want object | oas3-schema | Schemas  | $  

Seeming to indicate the entire file is invalid. However there are other warning messages output afterwards:

### `Operations` violations
<details><summary>⚠️️ Warnings: 4</summary>
⚠️️ operation-success-response: 4
| location | JSONPath                                                                |
| -------- | ----------------------------------------------------------------------- |
| `226:7`  | $.paths['/api/v1/restore-complete'].post.responses |

I don't know how to resolve the oas3-schema error. Any ways I can debug this as it occurs on a few, but not all, of the schemas I have tried.

[chipaca]

I have been running vacuum lint as part of a github action, and it's suddenly started doing this for me also (on one of my services, and not the other).

Location                    | Severity | Message                               | Rule        | Category | Path
specs/static/apiv4.yaml:0:0 | error    | schema invalid: got null, want object | oas3-schema | Schemas  | $   

[chipaca]

This is both with docker and running it as go run github.com/daveshanley/vacuum@v0.17.8 or go run github.com/daveshanley/vacuum@latest. I've also tried 0.17.x back to .0, so whatever it is it isn't new.

I have changed the yaml recently, particularly improving/fixing examples and some pattern regexps, but our other tools are OK with it so I dunno.

[lordnelson]

With some trial and error for a particular schema I noticed that this error appeared if the response codes weren't quoted. e.g.

      responses:
        202:

vs.

      responses:
        '202':

This might not be the cause of your error, if not then unfortunately it seems a case of trial and error. I will try and look to see if I can fix this specific problem myself to report a message and location, but as I'm not a Go developer it might take a while.

[chipaca]

That's exactly it! Well, almost. In one part of our API we have things that are objects where the keys are integers. In a recent change I added an example.

Here's a spec that vacuum is perfectly happy with (that is, a normal lint passes with no comments) but which reports a completely untractable error at line 0 column 0 if either the 200 or the 11 is left unquoted.

openapi: "3.0.0"
servers:
  - url: https://example.com/api/v1

info:
  title: API
  version: "0.1"
  description: Happy fun land

tags:
  - name: example
    description: An example operation

paths:
  /foo:
    get:
      operationId: Foo
      description: Get a Foo thing.
      tags: [example]
      responses:
        "200":
          description: The foo was got.
          content:
            application/json:
              schema:
                type: object
                example:
                  "11":
                    id: "eleven"

[daveshanley]

I will load this into my brain shortly for processing.

[daveshanley]

The problem:

The generic message with no location comes from JSON marshaling failure, the schema keys are numeric and that fails to be parsed by go's standard library. The null object is then passed to the validator, which says 'what the hell is this, I need something to parse, there is nothing" and returns, the useless error you see now.

The solution:

the schema needs to be unmarshaled before it goes in for validation. If it cannot be done, then we need to do it the hard way and parse and debug why we cannot unmarshal the structure, and then return an appropriate result that fails the rule and tells you why.

What you saw before:

and what you will see in the next release.

(I fixed the full paths too).

No more 0:0 cryptic nonsense, real error messages that help you understand and fix the problem.

[daveshanley]

fixed in v0.17.10

[chipaca]

Much better!

There's no reason you can't teach the yaml loader that those things are strings, but this works.