Regression for Top-Level Objects Resolution

[Smolations]

Originally posted in this swagger-ui issue thread, I have discovered an issue (I hope it isn't a feature, at least) around global parameter resolution.

After pulling in recent builds from each projects' develop_2.0 branches several days ago, I noticed that the page was taking longer to load than usual. I inspected the console/network panels and found that an initial call to fetch the api was made, followed by 5 more additional calls. It was tolerable and I assumed it was getting fixed, so I let it be. After adding several more paths to my api, I noticed the number grew to 11, significantly slowing the initial page load. None of the UI was rendering until all calls were complete. I believe I have finally pinned down the issue.

The resolver seems to be making new requests for the entire api each time it encounters a global parameter ref. I was able to pin this problem down to Resolver.prototype.resolve. When these global params are being resolved, a custom object is composed for the resolver's internal processing. This method checks for a property named root on that object. If it has a URL, a request for that resource is made for the resolver to process. Every global parameter ref made in the body schema points to the URL of the API passed to swagger-ui upon initialization, resulting in multiple calls to the same URL for resolution. With only 10 defined paths in my api response, the page load has slipped to 35 seconds or more.

Here is some console output for reference:

[lucian303]

+1

Is there a version where this doesn't occur that we could switch to until it gets fixed? Right now, it makes swagger-ui completely useless.

[ponelat]

I have a WIP, but its a little too WIP-like to use... will try to get it out there soon

[Smolations]

It seems that a short term fix would be to simply check the value of the URL and see if it matches the URL passed to swagger. If it's the same endpoint, use the current swagger config to resolve the global object. If it's different, then go ahead and make the request.

Whether the call gets made or not, it seems clear that there is no caching mechanism in place. If a call for a resource was already made, it is unlikely that the [remote] resource would change during the current session. IMHO, repeated API calls, whether buggy/valid, should only need to be made once and cached (not just the browser cache, but some JSON store during runtime) for some reasonable amount of time.

Thanks for your update @ponelat. I was beginning to wonder if there was any actual movement on this or if I had missed something. 😺

[fehguy]

OK @Smolations @lucian303 @ponelat I've identified the cause of this.

Take a look at #566 for the details