Path level $ref is not resolved

[mohsen1]

From swagger-api/swagger-editor#611

A simpler YAML to reproduce:

---
swagger: '2.0'
info:
  version: 0.0.0
  title: Simple API
paths:
  /:
   $ref: 'http://localhost:9000/root.json'

Inside root.json:

{
    "get": {
        "responses": {
            "200": {
                "description": "OK"
            }
        }
    }
}

After calling SwaggerApi#create the api.definition value is:

{
  "swagger": "2.0",
  "info": {
    "version": "0.0.0",
    "title": "Simple API"
  },
  "paths": {
    "/": {
      "$ref": "http://localhost:9000/root.json"
    }
  }
}

[whitlockjc]

The ref being in there as-is is because it cannot be resolved. If you look at the api.references information, you'll see that #/paths/~1 could not be resolved. This is working as designed unless you can tell me that sway is not resolving something it shouldn't.

[mohsen1]

Yes you need to spin up a server to serve the json file. It's not resolving even when the url is reachable

[whitlockjc]

I'll look into it. I also found: whitlockjc/json-refs#30 while working on this.

[whitlockjc]

Here is the test I'm using going forward:

---
swagger: '2.0'
info:
  version: 0.0.0
  title: Simple API
paths:
  /:
   $ref: 'http://petstore.swagger.io/v2/swagger.json#/paths/~1pet'

[whitlockjc]

I see this all over the editor.swagger.io console:

Uncaught (in promise) TypeError: Cannot read property 'petstore_auth' of undefined

Not sure if that's important or not.

[mohsen1]

In development version that error is not being thrown and instead shown to user. It's not finding the petstore security definitions in root swagger. Which makes sense.

I'm still able to reproduce the original error. I just checked, the XHR to root.json is being made and it's successful

[whitlockjc]

That error was the cause of the problem. This is an error in sway where we assume api.resolved.securityDefinitions is defined and when it's not, we get an error. When I fix that, remote references work as you'd expect. I'll fix this and get a release.

I'm not seeing a case where remote references do not work but once we fix this runtime issue, it should be easy to find since all unresolvable references (for whatever reason) are flagged as errors and we can see why.

[whitlockjc]

I'm not saying that this issue is fixed. I'm saying that when I fix sway not to bomb with the error above, remote references appear to work.

[whitlockjc]

sway@v0.2.2 is out. Try this and you should get the proper errors instead of a runtime failure. Come back to me with the unresolvable error information. (Disregard the missing references within the remote document as that is handled in json-refs/issues/30)

[mohsen1]

For resolution I'm using this proxy project so I can use web workers. It's a bit more work to update sway but I'll do it today

https://github.com/mohsen1/sway-worker

[whitlockjc]

json-refs/issues/30 has been fixed and sway@master is updated to use it. Once we know if this issue is still valid and if so, what the real problem is, we can fix it and get a new release out.

[whitlockjc]

json-refs/issues/30 has been re-opened but should be unrelated to this.

[whitlockjc]

Fixed. json-refs now has tests using the exact same document in the example above and it is working properly. I will update sway, again, and you'll need to let me know how this impacts things.

[whitlockjc]

sway@v0.2.3 has been released with a patched json-refs to better handle references to remote documents with local references. (json-refs has tests for remote references with and without fragments)

[whitlockjc]

With the last build of sway, I am no longer able to reproduce any of the issues encountered today.

[whitlockjc]

I'm marking this as closed since we've fixed the known issues that were reproducible but are no longer reproducible. Things appear to be working as expected in the latest release but feel free to re-open if you have more details.

[mohsen1]

Ok, I'll update you when I had a chance to try the new release.