nic-6443 opened a new pull request, #14055: URL: https://github.com/apache/apisix/pull/14055
### Description A disk-cache `PURGE` returns 200 and does delete the right cache file, but the next identical request still comes back as `HIT`. This affects both `proxy-cache` and `graphql-proxy-cache` (disk strategy). The cause is the `open_file_cache max=1000 inactive=60;` that the generated `nginx.conf` sets at the http level. nginx's file cache opens cache files through `open_file_cache`, so after a `HIT` the worker keeps the file descriptor around. `PURGE` removes the file from disk, but the keys zone entry is still valid, so the next request reuses the cached descriptor of the already-deleted file and serves it as a `HIT` until `open_file_cache_valid` (60s by default) runs out. The existing purge tests don't catch this because the test-nginx http config has no `open_file_cache`. The fix turns `open_file_cache` off in the location that serves proxy-cache / graphql-proxy-cache (and mirrors it in `t/APISIX.pm`). That location only uses open_file_cache for the proxy cache files, so nothing else changes; a cache hit now costs one `open()` of the cache file. The regression test is a CLI test (`t/cli/test_proxy_cache_purge.sh`) because it needs the real generated `nginx.conf`: MISS, HIT, PURGE, then expect MISS, for both plugins. It fails without the template change (`HIT` after purge) and passes with it. ### Checklist - [x] I have explained the need for this PR and the problem it solves - [x] I have explained the changes or the new features added to this PR - [x] I have added tests corresponding to this change - [ ] I have updated the documentation to reflect this change - [x] I have verified that this change is backward compatible -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
