Description

This pull request corrects an inconsistency where the analytics TimeStamp was recorded after the upstream response was received, rather than at the time of the initial request. This resulted in the timestamp reflecting the request's completion time, which could be misleading for analytics and did not align with the behavior implied in the official documentation.

By leveraging the request context, this change ensures the TimeStamp accurately reflects the moment the request first arrived at the gateway.

Changes Made:

1. ctx/ctx.go: Introduced RequestReceivedTime context key and helper functions (SetRequestReceivedTime, GetRequestReceivedTime).
2. gateway/reverse_proxy.go: In ServeHTTP, the request's arrival time is now captured and stored in the request context.
3. gateway/handler_success.go: The RecordHit function now retrieves the timestamp from the context instead of calling time.Now().

Related Issue

#7273

Motivation and Context

The primary motivation for this change is to improve the accuracy and clarity of analytics data. The previous implementation recorded a timestamp that was skewed by the upstream processing time, making it difficult to analyze true request arrival patterns. This fix aligns the TimeStamp field with its expected meaning – the moment the request is received by the gateway – which is crucial for accurate logging, monitoring, and debugging.

How This Has Been Tested

The changes have been tested by implementing the logic and verifying its flow through the relevant middleware components. The modifications are localized and leverage the standard request context for passing data, minimizing side effects.

• The context value is correctly set at the entry point in reverse_proxy.go.
• The context value is correctly retrieved at the exit point in handler_success.go before being written to the analytics record.

The code builds successfully, and a full run of the project's test suite is recommended to ensure no regressions have been introduced.

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 (No documentation changes are required as this aligns the code with the implied behavior of a "timestamp".)
• I explained why this PR updates go.mod in detail with reasoning why it's required (No go.mod changes)
• I would like a code coverage CI quality gate exception and have explained why (No exception required)