Rolling window limits?
Maintainers usually reply within 3 days
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 25/100
- Issue type
- Feature
- Clarity
- Needs clarification
- Activity status
- Stale
- Tech stack
- go
- Domain
- backend-api-design
Research direction
No file, test, or entry point is named. Read the rate-limit window implementation and the comment thread first, then compare its behavior with the two one-hour examples; done means the supported window semantics are confirmed or a concrete implementation scope is agreed.
Written by the indexing model from the issue text.
Description
Hi!
Does the library support rolling windows limits?
For example, if my limit is 60 per hour, there are 2 ways to go about it
- If the user hits the limit, she has to wait for 1 hour before the limit resets. Making even one call during the one hour time period will extend the limit by another hour. For example: if I made 60 calls in 1 hour, and then make one call in 1:59, I will be rate limited, and will have to wait for until 2:59 for the limit it reset )
- The limits get incremented as the time window slides, to always count only the events in the last hour. For example: if I made 60 calls in 1 hour (5 of which were in the first minute), and 1:01 I am allowed to make 5 more calls.
Based on reading the code, I think only 1 is supported, but just want to make sure
- Dominant language
- Go
- Stars
- 2.7k
- Forks
- 542
- Avg merge
- 5d 11h
- Merged PRs (30d)
- 10
Getting set up
- Ships a Dockerfile or Docker Compose file
- No pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from envoyproxy/ratelimit
-
Allow users to define the week start day for week-based rate limit setupsPossibly taken @divakaivan claimed this 4 days ago. Open
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
envoyproxy/ratelimit#1260 ·
Maintainers usually reply within 3 days
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
envoyproxy/ratelimit#1223 · 2 comments ·
Maintainers usually reply within 3 days
-
Validate Valkey as a Redis-protocol backend for the rate limit servicePossibly taken A pull request linked to this issue is open or already merged. Open
Difficulty 4/5 3-5 days Newbie friendliness 48/100
envoyproxy/ratelimit#1247 ·
Maintainers usually reply within 3 days
-
Difficulty 4/5 3-5 days Newbie friendliness 35/100
envoyproxy/ratelimit#1139 · 9 comments · 3 reactions ·
Maintainers usually reply within 3 days
-
help wanted
Difficulty 4/5 3-5 days Newbie friendliness 25/100
envoyproxy/ratelimit#358 · 3 comments ·
Maintainers usually reply within 3 days
All issues in envoyproxy/ratelimit
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
Maintainers usually reply within 1 day
-
[Bug] Extraction-mode autogen returns pod templates in random order for map-keyed CRDs, so deny and report messages change between runsPossibly taken @ManojLamani claimed this today. Open
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
kyverno/kyverno#17980 · 1 reaction ·
Maintainers usually reply within 1 day
-
raised-by:reviewer
Difficulty 1/5 1-3 hours Newbie friendliness 84/100
medici-finance/assay#2681 ·
Maintainers usually reply within 1 day
-
bug triaged
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
fullsend-ai/fullsend#8353 · 4 comments · 1 reaction ·
Maintainers usually reply within 1 day
-
duplication
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
openvibely/openvibely#1459 ·
Maintainers usually reply within 2 days