Error parsing valid (but odd) OpenAPI 3.0 spec

[jcstanaway]

My workflow for creating APIs includes using many re-usable components to drive consistency and commonality between the APIs in our project. This means I have a lot of $ref's to external files. Then, as part of a release & publication step, I use the NPM package RefParser to bundle all of these "source" files into a single YAML file with no external references. The result of this bundling can result in an odd looking, but valid, OpenAPI 3.0 specification. This specification validates against the official swagger 3.0 editor, but fails when attempting to import into Postman or converted with this tool.

The error is as follows:

$ openapi2postmanv2 -s $HOME/testapi.yaml
Input file:  C:\users\ccs018\testapi.yaml
ref #/components/responses/InternalError/headers/Retry-After not found.
C:\Users\ccs018\AppData\Roaming\npm\node_modules\openapi-to-postmanv2\bin\openapi2postmanv2.js:95
    if (!status.result) {
                ^

TypeError: Cannot read property 'result' of undefined
    at Converter.convert (C:\Users\ccs018\AppData\Roaming\npm\node_modules\openapi-to-postmanv2\bin\openapi2postmanv2.js:95:17)
    at module.exports (C:\Users\ccs018\AppData\Roaming\npm\node_modules\openapi-to-postmanv2\lib\convert.js:174:7)
    at Object.convert (C:\Users\ccs018\AppData\Roaming\npm\node_modules\openapi-to-postmanv2\index.js:10:14)
    at Object.<anonymous> (C:\Users\ccs018\AppData\Roaming\npm\node_modules\openapi-to-postmanv2\bin\openapi2postmanv2.js:91:13)
    at Module._compile (module.js:652:30)
    at Object.Module._extensions..js (module.js:663:10)
    at Module.load (module.js:565:32)
    at tryModuleLoad (module.js:505:12)
    at Function.Module._load (module.js:497:3)
    at Function.Module.runMain (module.js:693:10)

The source OpenAPI 3.0 spec is below. It's based on one of my bundled YAML file. The official swagger editor raises no complaints, but fails as noted above.

openapi: 3.0.1
info:
  title: My API
  version: 0.3.0
  description: >
    Fails to imported into Postman v6.7.0-canary02
components:
  responses:
    TooManyRequests:
      description: >
        `Too Many Requests`
      headers:
        Retry-After:
          # Odd forward reference that triggers the failure.
          $ref: '#/components/responses/InternalError/headers/Retry-After'
    InternalError:
      description: >
        `Internal Error`
      headers:
        Retry-After:
          description: >
            The Retry-After response HTTP header indicates how long the client
            should wait before retrying the request.
          required: false
          schema:
            oneOf:
              - type: string
                description: >-
                  A date after which to retry specified using the HTTP date
                  format (not the JSON datetime format).
              - type: integer
                minimum: 1
                exclusiveMinimum: false
                description: The number of seconds to delay after the response is received.
    ServiceUnavailable:
      description: >
        `Service Unavailable`
      headers:
        Retry-After:
          # This also causes a conversion failure.
          $ref: '#/components/responses/InternalError/headers/Retry-After'
paths:
  /myservice:
    post:
      requestBody:
        content:
          text/plain: {}
      responses:
        '200':
          description: >
            `OK`
          content:
            application/json: {}
          $ref: '#/components/responses/TooManyRequests'
        '500':
          $ref: '#/components/responses/InternalError'
        '503':
          $ref: '#/components/responses/ServiceUnavailable'

Only if I comment out both Retry-After $refs does it complete the conversion without error.

[abhijitkane]

@ccs018 #6 should address this

[jcstanaway]

Thanks for the quick turn around! Do you know how long it will be for a new version of Postman to be released with this fix?

[abhijitkane]

@ccs018 We'll be releasing the next Postman Canary version by tomorrow.

[jcstanaway]

Confirmed that [email protected] resolves this issue.