Jmax/LG-12134 Spike use absolute timestamps for rate limiter Redis timeouts.

[jmax-gsa]

🎫 Ticket

Link to the relevant ticket:
LG-12134

🛠 Summary of changes

Changed Redis calls in RateLimiter to always use absolute time values, instead of relative ones.

This change is internal to the timestamp class, and not visible outside it.

📜 Testing Plan

Provide a checklist of steps to confirm the changes.

• Verify that all existing specs pass.
• For each of the rate limiters in Handbook Rate Limiters Page , verify that the documented procedure for triggering each rate limiter still works as described.

[matthinz]

Am I correct that the goal here is to make it possible to time travel in specs to affect rate limiters (which was not previously possible?)

If so, can you add a test to rate_limiter_spec.rb that fails when expire is used but passes when expireat is used?

[mitchellhenke]

Similar to @matthinz's question, does this help situations like the test that initially led to trying the changes here?

[jmax-gsa]

Added a spec that fails if the redis calls use expire, but passes (now that we use) expireat

[jmax-gsa]

The basic problem stemmed from a mismatch between the Redis and Ruby timestamps.

Our tests allow for a one-second bobble, but between normal timing variations and the fact that we were sometimes using our clock, and sometimes Redis's, the bobble came to more than we tolerate sometimes, resulting in a few flaky specs.