fix(rate-limiter): avoid unnecessary GET when limiter key does not exist

[orolega]

Why

Fixes a Redis cache miss issue caused by getRateLimitTTL unconditionally calling GET on the rate limiter key on every job dequeue and completion, even when the key doesn't exist. Rate limiter keys are ephemeral — created on job processing via INCR and expiring after the configured duration. Between job executions the key is absent, so every GET returns nil, generating a cache miss.

Closes #3848

How

Added an EXISTS check in getRateLimitTTL.lua before the GET. When the key is absent — the common steady-state between rate limit windows — the function returns 0 immediately after a single EXISTS call, eliminating the miss-generating GET. The PTTL branches were also reordered so pttl > 0 returns early and pttl == 0 is an elseif, avoiding a redundant second condition check.

Tests covering all branches of the modified function were added to rate_limiter.test.ts under describe('getRateLimitTTL function behavior').

Additional Notes

[Copilot]

Pull request overview

Adds an EXISTS check in getRateLimitTTL.lua before the GET call to avoid unnecessary cache misses when the rate limiter key doesn't exist (the common case between rate limit windows).

Changes:

• Added EXISTS guard in getRateLimitTTL.lua to skip GET when the key is absent
• Reordered PTTL branches so pttl > 0 returns early before checking pttl == 0
• Added comprehensive tests for all branches of getRateLimitTTL

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

File	Description
src/commands/includes/getRateLimitTTL.lua	Added EXISTS check before GET; reordered PTTL branches
tests/rate_limiter.test.ts	Added tests covering all getRateLimitTTL branches

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

You can also share your feedback on Copilot code review. Take the survey.

[manast]

Thank you for your PR. In reality there is no need to issue an EXISTS first and then a GET, that would instead create more overhead as you need 2 Redis commands instead of just 1, and both have the same complexity. So really, this just makes it a bit slower than what we already have.