Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

References in referenced files not resolved #15

Open
dradetsky opened this issue Oct 9, 2020 · 2 comments · Fixed by #17 or #18
Open

References in referenced files not resolved #15

dradetsky opened this issue Oct 9, 2020 · 2 comments · Fixed by #17 or #18

Comments

@dradetsky
Copy link

suppose I have two files

# api.yaml
openapi: 3.0.3

info:
  title: chicken
  version: 0.0.0

paths:
  /get:
    post:
      operationId: getOneThing
      requestBody:
        $ref: '#/components/requestBodies/GetOneThingRequest'
      responses:
        200:
          $ref: '#/components/responses/GetOneThingResponse'

components:
  requestBodies:
    GetOneThingRequest:
      content:
        application/json:
          schema:
            $ref: 'schemas.yaml#/components/schemas/ThingKey'

  responses:
    GetOneThingResponse:
      description: one thing
      content:
        application/json:
          schema:
            $ref: 'schemas.yaml#/components/schemas/Thing'
# schemas.yaml
components:
  schemas:
    ThingKey:
      type: object
      properties:
        userId:
          type: integer
        thingId:
          type: integer
      required:
        - userId
        - thingId

    ThingData:
      type: object
      properties:
        lastSeen:
          type: string
          format: date-time
        value:
          type: integer
          
    Thing:
      type: object
      allOf:
        - $ref: '#/components/schemas/ThingKey'
        - $ref: '#/components/schemas/ThingData'

This is valid according to swagger-cli. However, if I run oapi2ts I get

stack: 'SyntaxError: Error resolving $ref pointer "#/components/schemas/ThingKey". \n' +
    'Token "schemas" does not exist.\n' +

However, if I change the definition of Thing to

    Thing:
      type: object
      allOf:
        - $ref: 'schemas.yaml#/components/schemas/ThingKey'
        - $ref: 'schemas.yaml#/components/schemas/ThingData'

It works correctly.

It almost seems as if the references are being resolved with respect to the original file they are given.

I can see that it might be very difficult to fix this issue with your current setup (which might require a stack of contexts or something equally awful). One option might be to look at using SwaggerParser.bundle at the beginning of execution to prevent this issue from arising.

mtrimolet added a commit that referenced this issue Oct 26, 2020
Local refs in refd schemas were resolved relative to top level schema.
Expected behavior is to resolve them relative to refd schema.

Refs: #15
mtrimolet added a commit that referenced this issue Oct 26, 2020
Local refs in refd schemas were resolved relative to top level schema.
Expected behavior is to resolve them relative to refd schema.

Refs: #15
@dradetsky
Copy link
Author

@mtrimolet So I just checked into this again after having worked around it in the past. It turns out that the fix was not actually successful. I added a broken test in the new PR to demonstrate.

@dradetsky
Copy link
Author

@mtrimolet FWIW, I may have made an error of communication in the original report here. I might have given you the impression that the above example, and more or less exactly the above example, was my actual use case. Therefore, if your fix caused the above example to work, the issue was solved. If so, this was a mistake on my part. The above example was just a simple way to demonstrate the references were not being resolved correctly.

This is why I suggested solving the problem with SwaggerParser.bundle. For just the above case, maybe it would be overkill. But for a fully-general solution to the issue of correctly resolving references in valid specs, it's probably much simpler than expanding your custom fix from #17.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
2 participants