fix(usage-limit): resolve race condition in usage tracker

[raushan728]

Description

The current implementation of UsageTracker uses a get() then increment() pattern (check-then-act), which is susceptible to race conditions under high concurrency. This PR refactors the logic to use an atomic increment() followed by a threshold check.

Changes

• Core Logic: Switched to atomic increment-then-check in check_usage_limit.
• Performance: Reduced Redis network calls from 2 to 1 per request.
• Reliability: Updated cache_validator tests to use port 54321 to ensure consistent failure assertions regardless of local Redis instances running on the default port.

Verification Results

• All unit tests passed: 386 passed; 0 failed.
• Manually verified that usage limits are strictly enforced.

---

Important

Refactor UsageTracker to use atomic increment for usage limits, reducing Redis calls and improving reliability.

• Core Logic:
  • Refactor check_usage_limit in usage_tracker.rs to use atomic increment() before checking limits.
• Performance:
  • Reduce Redis calls from 2 to 1 per request in usage_tracker.rs.
• Reliability:
  • Update cache_validator.rs tests to use port 54321 for consistent failure assertions.
• Tests:
  • Remove test_usage_limit_store_get_error_fallback_enabled and test_usage_limit_store_get_error_fallback_disabled from usage_tracker.rs.

^{This description was created by for 38c9fe7. You can customize this summary. It will automatically update as commits are pushed.}

[ellipsis-dev]

Important

Looks good to me! 👍

Reviewed everything up to 38c9fe7 in 46 seconds. Click for details.

• Reviewed 105 lines of code in 2 files
• Skipped 0 files when reviewing.
• Skipped posting 2 draft comments. View those below.
• Modify your settings and rules to customize what types of comments Ellipsis leaves. And don't forget to react with 👍 or 👎 to teach Ellipsis.

1. crates/lib/src/usage_limit/usage_tracker.rs:67

• Draft comment:
  Good refactoring: using an atomic increment avoids the race condition and cuts down on network calls. Please ensure that casting self.max_transactions to u32 is safe (i.e. it cannot exceed u32::MAX).
• Reason this comment was not posted:
  Comment did not seem useful. Confidence is useful = 0% <= threshold 50% The comment is asking the author to ensure that a casting operation is safe, which violates the rule against asking the author to ensure behavior is intended or safe. It does not provide a specific suggestion or ask for a specific test to be written.

2. crates/lib/src/validator/cache_validator.rs:172

• Draft comment:
  Using port 54321 instead of the default 6379 in tests ensures connection failure if a local Redis is running, which makes the tests more reliable.
• Reason this comment was not posted:
  Comment did not seem useful. Confidence is useful = 0% <= threshold 50% This comment is purely informative, explaining why a certain port is used in tests. It doesn't provide a suggestion, ask for confirmation, or point out a potential issue. Therefore, it violates the rule against making purely informative comments.

Workflow ID: wflow_GTrDoZ1oIj5S26ng

^{You can customize by changing your verbosity settings, reacting with 👍 or 👎, replying to comments, or adding code review rules.}

[raushan728]

Note: The atomic increment logic from this PR is also included in #277, which provides a more comprehensive update (SignerPool failover, Token-2022 security, etc.). I recommend reviewing #277 first. If you choose to merge that, this PR can be closed. However, if you'd like to merge this small fix independently, I am happy to resolve the resulting conflict in #277 afterward.

[dev-jodee]

lgtm, will merge this one even if another pr includes it so we keep a good separation