mirror of
https://github.com/yu-i-i/overleaf-cep.git
synced 2026-11-13 21:53:43 +01:00
* Fix negative AI quota countdown after reset period elapses Backend (`FeatureUsageRateLimiter`, `TokenUsageRateLimiter`): once the 24h period had lapsed, `remainingUsage`/`remainingTokens` reset to the full allowance but `resetDate` kept pointing at the old `periodStart + 24h` (i.e. in the past). Advance to `now + 24h` in that case. Frontend (`NewPlanPaywall`, `ErrorGetPremium`): the "wait X hours and Y minutes" copy computed `restoreTime - now` without clamping, so a past `restoreTime` produced negative hours/minutes (users saw "wait -118 hours and -35 minutes"). Clamp to 0. * Address PR review on quota reset fix - Keep `resetDate` tied to the stored `periodStart + PERIOD` rather than jumping to `now + PERIOD` when the period has lapsed. The moving-target variant unnecessarily reinterpreted a stable field (existing consumers such as `use-ai-access-gate` check whether the reset date is in the past). - Clamp `remainingUsage` / `remainingTokens` at 0 so a concurrent over-usage never leaks a negative count. - Align the boundary check with `_checkRateLimit` / `checkUsage` (inclusive `<=`). - Cover the period boundary and the clamp in unit tests for both `FeatureUsageRateLimiter` and `WorkbenchRateLimiter`. * Truncate test fixtures to whole seconds `resetDate` is serialized with `Date.toString()`, which has second resolution, so fixtures with a millisecond component failed the boundary assertions. * Revert code changes; keep tests that document the bug The fixes masked the symptom (negative countdown) without addressing the underlying issue, and it is not fully understood yet. Revert the rate limiters and the writefull paywall components to their original behaviour, and instead pin the current behaviour in tests: - `it.fails` tests document that `remainingUsage`/`remainingTokens` go negative when usage exceeds the allowance — these flip red when the bug is fixed, at which point they should become plain `it`. - The lapsed-period tests assert (with explanatory comments) that `resetDate` keeps pointing at the end of the lapsed period, which is the server-side ingredient of the negative-countdown support ticket. * Reapply quota fixes Restores the post-review state of the rate limiters (clamp remaining counts at 0, inclusive period boundary, resetDate tied to periodStart) and the writefull paywall components (clamp countdown at 0). Tests intentionally untouched in this commit; the two `it.fails` tests now need flipping to plain `it` in a follow-up. * Flip bug-documenting tests to plain assertions The clamp fixes are reapplied, so the `it.fails` tests now assert the fixed behaviour directly. Trim the explanatory comments. * Set resetDate to `Date.now() + PERIOD_IN_MILLISECONDS` instead of the expired/stale date. Co-authored-by: Mathias Jakobsen <mathias.jakobsen@overleaf.com> * Update lapsed-period tests for the fresh resetDate `resetDate` is now `Date.now() + PERIOD` once the period has lapsed, so assert an approximately-fresh date instead of the stale period end. --------- Co-authored-by: Mathias Jakobsen <mathias.jakobsen@overleaf.com> GitOrigin-RevId: ad39627ab9e5ceccb2a61443b2b7d39c68600594