tyk
tyk copied to clipboard
feat/TT-9462/tag-cached-response
User description
Description
For users of our redis cache there is currently no simple way to slice the analytics or log data in the dashboard by whether that traffic is cached from Tyk or not.
This feat adds a simple case that adds the tag "cached-response" anytime a response is served from our redis cache.
Related Issue
https://tyktech.atlassian.net/browse/TT-9462
How This Has Been Tested
- Create API and enable caching - all safe request or per endpoint is a good option to test. It doesnt not make any difference which you choose.
- send more than one request to the API
- Check analytics and logs in Tyk dashboard, you can filter graphs by tag "cached-response" to split cached and non cached counters
- Check log browser, response will contain "cached-response" tag when the cache hit occurs
Screenshots (if appropriate)
Types of changes
- [ ] Bug fix (non-breaking change which fixes an issue)
- [x] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing functionality to change)
- [ ] Refactoring or add test (improvements in base code or adds test coverage to functionality)
Checklist
- [ ] I ensured that the documentation is up to date
- [ ] I explained why this PR updates go.mod in detail with reasoning why it's required
- [ ] I would like a code coverage CI quality gate exception and have explained why
PR Type
Enhancement
Description
- Enhanced the
RecordHit
function to accept acached
parameter. - Added logic to tag responses with
cached-response
if they are served from the cache. - Updated various middleware components to pass the
cached
parameter toRecordHit
.
Changes walkthrough 📝
Relevant files | |||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Enhancement |
|
💡 PR-Agent usage: Comment
/help
on the PR to get a list of all available PR-Agent tools and their descriptions