I was testing our I/O caching and it seems it stopped working , we are always getting a X-Cache: CONFIG_CACHE response header (which was not there before) and this results in the x-gw-cache always being a MISS although the cache-control header states max-age=300.
We tested it via both browser and postman after unchecking the disable cache checkbox. Also we made sure that the request is a GET request and not POST.
Everything was working fine since long time as you can see below
But now, its always a MISS or BYPASS
Would it be possible to provide one of the executed URLs?
The cache should activate in case the action is configured with 'Cache-Control': 'max-age=..` and the URL is exactly the same for consecutive requests.
Hi @arpangarg yes, the way it works now is that all requests that are sent to web actions are cached when using the `/api/v1/web/*`, and are not cached when using `/apis/*`. However we agree that this is not how it's supposed to be and we're going to add a fix by next week. I will update this thread when it was deployed to production.
Hi @arpangarg sorry for the delay. Yes we have investigated the issue, and we have concluded that the wsk cli in its default form, doesn't create a cacheable path. Caching only works if the api endpoints are created using swagger. However, we have 2 solutions for you as we do think that your expectation of how the apis caching should work, is correct:
1. You would have to change the api configuration for that particular action and add a "response-type" with an "http" as value to your command.
For example if your action is called "cache_action", the base path is "test" and the api path is cache_action_path, the the following command will recreate the route and will activate caching for that particular action:
# wsk api create /test /cache_action_path GET cache_action --response-type http
2. With future versions, we'll update the current implementation, so that "--response-type" is not mandatory for activating caching for an api route.
I'll be happy to help with any additional questions you might have.
Hi @stanciu - The IO started caching our requests now without us doing any of the changes you mentioned. We are not using --response-type http in our api configuration but still it is working.
Did your team fixed it ?