Antoine ClausseandMathias Jakobsen
87fd22cefc
* 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
An open-source online real-time collaborative LaTeX editor.
Wiki • Server Pro • Contributing • Mailing List • Authors • License
Figure 1: A screenshot of a project being edited in Overleaf Community Edition.
Community Edition
Overleaf is an open-source online real-time collaborative LaTeX editor. We run a hosted version at www.overleaf.com, but you can also run your own local version, and contribute to the development of Overleaf.
Caution
Overleaf Community Edition is intended for use in environments where all users are trusted. Community Edition is not appropriate for scenarios where isolation of users is required due to Sandbox Compiles not being available. When not using Sandboxed Compiles, users have full read and write access to the
sharelatexcontainer resources (filesystem, network, environment variables) when running LaTeX compiles.
For more information on Sandbox Compiles check out our documentation.
Enterprise
If you want help installing and maintaining Overleaf in your lab or workplace, we offer an officially supported version called Overleaf Server Pro. It also includes more features for security (SSO with LDAP or SAML), administration and collaboration (e.g. tracked changes). Find out more!
Keeping up to date
Sign up to the mailing list to get updates on Overleaf releases and development.
Installation
We have detailed installation instructions in the Overleaf Toolkit.
Upgrading
If you are upgrading from a previous version of Overleaf, please see the Release Notes section on the Wiki for all of the versions between your current version and the version you are upgrading to.
Overleaf Docker Image
This repo contains two dockerfiles, Dockerfile-base, which builds the
sharelatex/sharelatex-base image, and Dockerfile which builds the
sharelatex/sharelatex (or "community") image.
The Base image generally contains the basic dependencies like wget, plus texlive.
We split this out because it's a pretty heavy set of
dependencies, and it's nice to not have to rebuild all of that every time.
The sharelatex/sharelatex image extends the base image and adds the actual Overleaf code
and services.
Use make build-base and make build-community from server-ce/ to build these images.
We use the Phusion base-image
(which is extended by our base image) to provide us with a VM-like container
in which to run the Overleaf services. Baseimage uses the runit service
manager to manage services, and we add our init-scripts from the server-ce/runit
folder.
Contributing
Please see the CONTRIBUTING file for information on contributing to the development of Overleaf.
Authors
License
The code in this repository is released under the GNU AFFERO GENERAL PUBLIC LICENSE, version 3. A copy can be found in the LICENSE file.
Copyright (c) Overleaf, 2014-2025.