How to retrieve remaining rate limits from Convex's rateLimiter?
Hi!
I'm trying to figure out how to get the remaining number of requests allowed with the rateLimiter component. When I use the rateLimiter.limit call, it only tells me whether the limit is OK (ok/retryAfter), but it doesn’t provide how many requests are left.
I noticed that the rateLimiter component has a rateLimits table, which seems to contain the rate limit data. However, when I try to use a query to read this table, I can only access the data from the app component and not the rateLimiter component.
Is there a way to directly query the rateLimiter component’s rateLimits table? Or is there another way to get the remaining request count from rateLimiter.limit?
Thanks in advance for your help!
7 Replies
Thanks for posting in <#1088161997662724167>.
Reminder: If you have a Convex Pro account, use the Convex Dashboard to file support tickets.
- Provide context: What are you trying to achieve, what is the end-user interaction, what are you seeing? (full error message, command output, etc.)
- Use search.convex.dev to search Docs, Stack, and Discord all at once.
- Additionally, you can post your questions in the Convex Community's <#1228095053885476985> channel to receive a response from AI.
- Avoid tagging staff unless specifically instructed.
Thank you!
I don't believe there's a way to get straight at the tables without changing some things in the component itself, and you also want to generally avoid that as the component could change it's internals in a way that breaks your code.
Just to help fill out the feature request here, can you share your use case for requiring number of requests left?
I have also asked for this here, unfortunately my conversations in the beta components channel i no longer have access to. I have been meaning to put a reminder in.. https://github.com/get-convex/rate-limiter/issues/2
GitHub
Request: exposing token utilization, getValue · Issue #2 · get-conv...
This is a following conversation in the beta components thread. Context: Currently the api only provides you the next time that you can retry at. We reverse engineered the convex helper rate limite...
Using the old convex helpers library we could access the table directly and we built a whole component that shows your current throttle availability of that users rate limit(it would not be sharded) if you can take another action. Sharding would make our throttle component messy. We may have background processes that may fire eating into the throttle so we cant rely on retryAfter.
cc/ @ian
Yeah sorry for the delay on that. A couple questions for you and @Rane while it's on top of mind:
1. It can return an estimate based on a few shards, so it's not getting invalidated on every request, or have it query all shards. If you're using it in a query, it won't cause data conflicts, but will re-run frequently, but will have the most up-to-date quantity.
2. It could provide a query you could re-export in your app / root component, paired with a React hook like
const { ok, retryAt, value } = useRateLimit(api.foo.exportedQuery, { count?, estimate? })
3. In the case of sharding, is it ok for value to reflect overall capacity, even if a given request will likely only have value/shards available to it?
For tracking usage, it depends if you want to surface that data later (e.g. per-day or mor granular data). If so, I'd store it in an aggregate, namespaced by user, with a sumValue set. If you don't care about when they used it, but want to know their total overall usage, I'd use a sharded counter with a key of their userId. Both can be used alongside a rate limiter, updated at the same time. The rate limiter is space-optimized to not store historical data, just enough to provide rate limiting.beauty 🙏🥹
thanks for your perspective
I’ll do this approach!