ParseRetryAfterHeaderValue may mishandle X-RateLimit-Reset epoch timestamps

[coderabbitai]

Description

The ParseRetryAfterHeaderValue function in internal/utils/retryutils/retryutils.go correctly handles both delta-seconds and HTTP-date formats for the Retry-After header, but applies this same logic uniformly to X-RateLimit-Reset headers.

In practice, X-RateLimit-Reset headers often use epoch timestamps (e.g., GitHub API returns epoch seconds) rather than relative seconds. The current implementation may incorrectly interpret epoch timestamps as massive relative delays or produce incorrect retry behavior.

Potential Impact

• Incorrect retry delays when interacting with APIs that use epoch timestamps in X-RateLimit-Reset headers
• Silent failures where retry logic doesn't behave as expected

Suggested Approach

Either:

1. Add format detection to distinguish epoch timestamps (typically 10+ digits) and convert appropriately
2. Document clearly which header formats are supported and validate inputs to reject unexpected formats

Related PR/Comment

• PR: chore: reduce generated files #248
• Comment: chore: reduce generated files #248 (comment)
• Raised by: @coderabbitai