resolveFully doesn't resolve nested schemas

[rivancic]

I would like to resolve schemas in the following OAS file.

openapi: 3.0.0
info:
  title: std classes
  version: 1.0.0
  contact:
    name: Contact name
    email: contact@mail.com
paths: {}
components:
  schemas:
    MessageCategory:
      type: string
      description: The category describing the severity of the message.
      enum:
        - INFO
        - ERROR
        - WARN
    ResponseMessage:
      type: object
      description: Common response message object.
      required:
        - category
      properties:
        category:
          $ref: "#/components/schemas/MessageCategory"

But if I invoke OpenAPIV3Parser#readLocation() with ParseOptions.resolveFully set to true, category property inside ResponseMessage is not being resolved to the actual object itself. It is still defined as $ref pointing to MessageCategory.

Example of the parsed result, where you can clearly see that the schema wasn't resolved.

Is resolving of schemas intentionally not supported if the OAS file contains schemas only?
How can I resolve schema without writing some dummy paths that contain those schemas in request or response?
For me it seems obvious that MessageCategory will be resolved inside ResponseMessage if resolveFully is set to true.

[gracekarina]

Hi, @rivancic, parser supports resolveFully for references that are not local, as explained here:
https://github.com/swagger-api/swagger-parser#2-resolvefully.
I will check if it makes sense to add a ParseOption like ResolveFullSchemas or something, to allow the behaviour you need when set to true.

[gracekarina]

Hi, @rivancic So I double checked, and the main cause for this to happen id because there are no Paths in the spec, so the resolveFully behaviour is not triggered.

[rivancic]

Thanks for the @gracekarina for the prompt response! I just wanted to make sure there is no out of the box solution.

I have the requirement where in one file I have predefined component schemas, and only that, no paths are defined there. Those will be used to validate definition of schemas in other Open API Specification files. But they need to be resolved in order that I will have then consistent results.

To customize this behavior I see I could extend OpenAPIV3Parser and override readLocation() other required methods and also extend ResolverFully class.

[rivancic]

I was just wondering if nobody else got similar requirements ❔

Otherwise this issue can be closed.

[gracekarina]

Hi, @rivancic no one has asked so far. Thanks!