feat/TT-9462/tag-cached-response

[joshblakeley]

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

1. 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.
2. send more than one request to the API
3. Check analytics and logs in Tyk dashboard, you can filter graphs by tag "cached-response" to split cached and non cached counters
4. 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)
• 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 a cached 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 to RecordHit.

---

Changes walkthrough 📝

Relevant files

Enhancement

coprocess.go Add `cached` parameter to `RecordHit` function call.          gateway/coprocess.go Updated RecordHit function call to include a cached parameter. +1/-1      handler_success.go Enhance `RecordHit` function to tag cached responses.        gateway/handler_success.go Modified RecordHit function to accept a cached parameter. Added logic to append cached-response tag if cached is true. Updated ServeHTTP and ServeHTTPWithCache functions to call RecordHit with cached parameter. +7/-3      mw_go_plugin.go Add `cached` parameter to `RecordHit` function call.          gateway/mw_go_plugin.go Updated RecordHit function call to include a cached parameter. +1/-1      mw_redis_cache.go Tag responses from Redis cache as cached.                                gateway/mw_redis_cache.go Updated RecordHit function call to include a cached parameter set to true. +1/-1      mw_virtual_endpoint.go Add `cached` parameter to `RecordHit` function call.          gateway/mw_virtual_endpoint.go Updated RecordHit function call to include a cached parameter. +1/-1

---

💡 PR-Agent usage:
Comment /help on the PR to get a list of all available PR-Agent tools and their descriptions

[github-actions]

PR Description updated to latest commit (dc1f951)

[github-actions]

API Changes

--- prev.txt	2024-05-31 17:08:36.552469898 +0000
+++ current.txt	2024-05-31 17:08:33.420457860 +0000
@@ -9871,7 +9871,7 @@
     SuccessHandler represents the final ServeHTTP() request for a proxied API
     request
 
-func (s *SuccessHandler) RecordHit(r *http.Request, timing analytics.Latency, code int, responseCopy *http.Response)
+func (s *SuccessHandler) RecordHit(r *http.Request, timing analytics.Latency, code int, responseCopy *http.Response, cached bool)
 
 func (s *SuccessHandler) ServeHTTP(w http.ResponseWriter, r *http.Request) *http.Response
     ServeHTTP will store the request details in the analytics store if necessary

[github-actions]

PR Review 🔍

⏱️ Estimated effort to review [1-5]	2, because the changes are straightforward and localized to specific functions, mainly adding a boolean parameter to handle cache tagging.
🧪 Relevant tests	No
⚡ Possible issues	Possible Bug: The cached boolean is always set to false in several files except in mw_redis_cache.go. This might not reflect the actual cached state in all scenarios, potentially leading to inaccurate analytics.
🔒 Security concerns	No

Code feedback:

---

relevant file	gateway/handler_success.go
suggestion	Consider adding a check for the cached parameter before appending the "cached-response" tag to ensure it's only added when appropriate. This can prevent potential issues where the tag might be added incorrectly due to future changes in logic. [important]
relevant line	tags = append(tags, "cached-response")

---

relevant file	gateway/mw_redis_cache.go
suggestion	Ensure that the cached parameter is accurately set throughout all relevant middleware functions, not just in mw_redis_cache.go, to maintain consistency and accuracy in analytics tagging. [important]
relevant line	m.sh.RecordHit(r, analytics.Latency{Total: int64(ms)}, newRes.StatusCode, newRes, true)

---

relevant file	gateway/coprocess.go
suggestion	Review the hardcoded false for the cached parameter to ensure it aligns with the actual response state. This might require additional logic to determine if the response was cached. [important]
relevant line	m.successHandler.RecordHit(r, analytics.Latency(analytics.Latency{Total: int64(ms)}), int(returnObject.Request.ReturnOverrides.ResponseCode), res, false)

---

relevant file	gateway/mw_go_plugin.go
suggestion	Similar to other middleware, verify if the response from the Go plugin middleware can be cached and set the cached flag accordingly to ensure accurate analytics. [important]
relevant line	successHandler.RecordHit(r, analytics.Latency{Total: int64(ms)}, rw.statusCodeSent, rw.getHttpResponse(r), false)

---

[github-actions]

PR Code Suggestions ✨

Category	Suggestion	Score
Best practice	Ensure consistent use of the cached parameter in RecordHit calls Ensure that the cached parameter is consistently used across all invocations of RecordHit to maintain the integrity of analytics tracking. gateway/handler_success.go [384] -s.RecordHit(r, latency, resp.Response.StatusCode, resp.Response, false) +s.RecordHit(r, latency, resp.Response.StatusCode, resp.Response, cached) Suggestion importance[1-10]: 8 Why: Ensuring the cached parameter is consistently used across all invocations of RecordHit is important for maintaining the integrity of analytics tracking, making this a valuable suggestion.	8
Maintainability	Extract the tag appending logic into a separate method to enhance readability and maintainability To improve the readability and maintainability of the RecordHit method, consider extracting the tag appending logic into a separate method. gateway/handler_success.go [204-206] -if cached { - tags = append(tags, "cached-response") +func (s *SuccessHandler) appendTags(tags []string, cached bool) []string { + tags = append(tags, s.Spec.Tags...) + if cached { + tags = append(tags, "cached-response") + } + return tags } Suggestion importance[1-10]: 7 Why: Extracting the tag appending logic into a separate method can improve readability and maintainability by encapsulating the logic and making the RecordHit method cleaner.	7
Enhancement	Optimize the handling of the cached parameter in the RecordHit method Refactor the RecordHit method to handle the cached parameter more efficiently by directly appending it to the tags if true. gateway/handler_success.go [204-206] +tags = append(tags, s.Spec.Tags...) if cached { tags = append(tags, "cached-response") } Suggestion importance[1-10]: 3 Why: The suggested refactor does not provide a significant improvement in efficiency or readability. The current implementation is already straightforward and clear.	3

[padiazg]

LGTM

[sonarcloud]

Quality Gate passed

Issues
0 New issues
1 Accepted issue

Measures
0 Security Hotspots
75.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarCloud