List cases where cacheing is good vs bad in the resolver

[ponelat]

We need to establish a cacheing policy that is safe and explicit ( and tested )

• Don't cache any try-it-out or arbitrary requests
• Cache http requests within a single resolver invocation
• Allow holding onto a cache across multiple resolver invocations ( ie: external cache management ).

ping @fehguy @webron @buunguyen please ensure the list above it accurate. Once it is we can implement the tests ( and the implementation too ).

[buunguyen]

Is this the list of "all cache mechanisms we need to support"? Or are we supposed to pick a single cache strategy that works?

How about a 4th option: cache within the same swagger client instance. If users need new cache, they can just create a new instance.

[ponelat]

@buunguyen I believe all hold true, and yes - I also agree with cacheing per instance.
The importance of this issue is to make sure these cases are tested and accounted for.

[buunguyen]

@webron this is P1. I don't know what to do about this. Is there a bug that this would fix?

[webron]

There is a bug, as far as I know. @ponelat should be able to explain it.

[ponelat]

We cache resolver requests for the lifetime of the browser page. That is the primary bug. We'd also like to invalidate pieces of the cache, but that's a nice to have... and we can already do that in some ways.

We also see this in failing tests... where we cache results globally ( there was an outdated PR that tried to fix that ). To solve it there, we can just dump the cache after test runs.

I don't think this is a high priorty, probably P2? @webron

[shockey]

I just touched on this issue in my $ref interceptor PR - and needed to flush the cache after each test run: https://github.com/swagger-api/swagger-js/pull/1161/files#diff-910eb6f57886ca16c136101fb1699231R497

A per-instance cache would fix this. I agree with @ponelat, this is probably better as a P2 item (@webron).