Getting errors but also "Linting passed, A perfect score!"

[jrudder]

Not sure if this is issue-worthy, so I figured I'd start here with a discussion. I've created a minimal test here: https://github.com/jrudder/vacuum-test

When linting the nested file structure, vacuum reports errors but also states linting passed with a perfect score. See below for example output. I did a little digging and found that the error comes from libopenapi (specifically here: https://github.com/pb33f/libopenapi/blob/8b9ef11270d01593fb1afa501f0384ca9a59df0a/datamodel/low/v3/paths.go#L158). But that's as far as I could go at this point.

My questions:

• Is it reasonable to get an error but also have linting passed?
• If yes, should I ignore such libopenapi errors in general? (Or perhaps, they should be automatically suppressed by vacuum if linting succeeds?)
• Is the nested structure... reasonable? Or is there a better way to write multi-file, nested directory specifications? (I did look at vacuum's test_files for inspiration but didn't see an example using subdirs.)

██╗   ██╗ █████╗  ██████╗██╗   ██╗██╗   ██╗███╗   ███╗
██║   ██║██╔══██╗██╔════╝██║   ██║██║   ██║████╗ ████║
██║   ██║███████║██║     ██║   ██║██║   ██║██╔████╔██║
╚██╗ ██╔╝██╔══██║██║     ██║   ██║██║   ██║██║╚██╔╝██║
 ╚████╔╝ ██║  ██║╚██████╗╚██████╔╝╚██████╔╝██║ ╚═╝ ██║
  ╚═══╝  ╚═╝  ╚═╝ ╚═════╝ ╚═════╝  ╚═════╝ ╚═╝     ╚═╝


version: 0.4.5 | compiled: 2023-11-09T13:52:01Z
🔗 https://quobix.com/vacuum | https://github.com/daveshanley/vacuum


 INFO  Linting against 42 rules: https://quobix.com/vacuum/rulesets/recommended
{"time":"2023-11-14T16:23:03.0938-08:00","level":"ERROR","msg":"error building path item 'schema build failed: reference 'user.model.yaml#/User' cannot be found at line 11, col 21'"}
{"time":"2023-11-14T16:23:03.094178-08:00","level":"ERROR","msg":"error building path item 'schema build failed: reference 'user.model.yaml#/User' cannot be found at line 11, col 21'"}


                                                               
          Linting passed, A perfect score! well done!  

[daveshanley]

Hi,

There are two items to discuss, one is the nested files. There is a new -u / -remote flag that will resolve those files for you automatically, and if the references are in some other directory/location outside your working directory, then you can use the --base flag to tell libopenapi where to resolve from.

It's perfectly fine to use nested files, libopenapi recently added a new advanced component called 'the rolodex' that can resolve anything, anywhere and in any combination of local files or remote files.

The second item is should a bad document pass?

I actually think this is a bug, those path errors are returned libopenapi (the logs show it's caught it), however it's not been picked up by vacuum when running rules. It's a gap I think you have discovered, as all this is new code added in the last couple of weeks.

There is a topic on this here: #351 (comment)

[jrudder]

Thanks for the quick reply. I browsed through the issue you referenced, and it covers a lot of what I have run into while troubleshooting with various combinations of --remote and --base. I will try to use the solutions there as a starting point and see where that takes me.

I'll close this discussion in the meantime. Thanks again.