Use monotonic clock for rate limiting

[chrarnoldus]

Kilo PR: Kilo-Org/kilocode#2583

Related GitHub Issue

Maybe fixes: #7770

Description

We received reports from users being rate limited for long periods (longer than the maximum 60s allowed in the UI) without ever enabling the rate limiter (one user mentioned using a laptop with a bad battery). This PR aims to rectify this issue by replacing the non-monotonic Date.now by the monotonic performance.now. Additionally, a check was introduced to never rate-limit for longer than the configured time.

Pre-Submission Checklist

• Issue Linked: This PR is linked to an approved GitHub Issue (see "Related GitHub Issue" above).
• Scope: My changes are focused on the linked issue (one major feature/fix per PR).
• Self-Review: I have performed a thorough self-review of my code.
• Testing: New and/or updated tests have been added to cover my changes (if applicable).
• Documentation Impact: I have considered if my changes require documentation updates (see "Documentation Updates" section below).
• Contribution Guidelines: I have read and agree to the Contributor Guidelines.

Screenshots / Videos

before:

Additional Notes

Also changed the background usage collecting to use performance.now

Get in Touch

Christiaan in shared Slack

---

Important

Replace Date.now with performance.now for monotonic clock usage in rate limiting and add a check to prevent exceeding configured time.

• Behavior:
  • Replace Date.now with performance.now in Task.ts for monotonic clock usage in rate limiting.
  • Add check to prevent rate limiting beyond configured time in Task.ts.
• Tests:
  • Update tests in Task.spec.ts to mock performance.now for simulating time passage.
  • Ensure rate limiting logic is correctly enforced and tested in Task.spec.ts.

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

[ellipsis-dev]

When overriding performance.now here, consider wrapping the override in a try…finally block so that the original function is always restored even if the test fails.

[roomote]

I found some issues that need attention related to rate-limit delay computation clarity and test robustness.

[roomote]

P2: Now that this uses a monotonic clock, consider extracting this remaining-delay calculation into a small helper (with unit tests) to make the ms→s conversion and clamping intent explicit. For example: min(rateLimitSeconds, ceil(max(0, remainingMs)/1000)). This helps avoid future regressions and clarifies that lastGlobalApiRequestTime and now are performance.now() values (ms, monotonic).

[roomote]

P3: Instead of reassigning performance.now directly, prefer vi.spyOn(performance, 'now').mockReturnValue(...) and restore with mockRestore(). This avoids mutating globals and plays nicer with parallel tests.