Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Rate-limit handling to count requests

Abierto
  • ¿Algo no está bien?
#697 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
35/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Tranquilo
Stack tecnológico
python
Área
backend

Línea de trabajo

Start by reading BaseDAVClient._rate_limit_sleep_seconds() and the rate-limit decorator setup in tests/test_caldav.py around line 1412. Compare the existing reactive client behavior with the test framework’s fixed-delay behavior, then decide where request counting belongs. Done means the chosen approach respects the declared interval and count without delaying requests while budget remains.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

enhancement

Currently the rate-limit throttling is done very simple - if it's allowed, say, to send 30000 requests within a 30000 second window, it will sleep 1s between each request.

Two alternative methods should be considered:

  • Send 30000 requests without any throttling, then sleep out the window.
  • Send the first request without any throttling, then add a progressingly growing delay so that there will never be a long complete halt when the quota has been reached.

The description below was AI-generated and seems to follow the first
method suggested above.

There are two separate pieces of rate-limit machinery today, and neither counts
requests.

The client is purely reactive. BaseDAVClient._rate_limit_sleep_seconds()
only ever runs after the server has answered 429 (or 503 with Retry-After).
It sleeps Retry-After, or default_sleep, capped by max_sleep, and retries.
Nothing tracks how many requests have been sent, so the client walks into the
throttle every time and then waits it out.

The test framework throttles pre-emptively, with a fixed delay per request.
tests/test_caldav.py around line 1412:

foo = self.is_supported("rate-limit", dict)
if foo.get("enable"):
    rate_delay = foo.get("interval", 0) / foo.get("count", 1)
    self.caldav.request = _delay_decorator(self.caldav.request, t=rate_delay)

So a server declaring interval: 300, count: 1500 gets 300 / 1500 = 0.2
seconds of sleep before every request, including the first, when the whole
budget is still unspent. A run that makes a few thousand requests pays minutes
for it. For ecloud, which declares interval: 2, count: 1, it is 2 seconds per
request.

What it should do instead

Count. A token bucket, or simply a deque of the timestamps of requests inside
the window:

  • under budget → send immediately, no sleep at all;
  • budget spent → sleep exactly long enough for the oldest request in the window
    to age out, not a fixed slice.

With 1500 per 300s that means the first 1500 requests go through at full speed
and only a run that genuinely exceeds the server's budget ever waits.

Where it belongs

Arguably in the client rather than the test framework, so that real users get it
too: a client that knows a server's published limits can stay under them instead
of discovering them through 429s. The test framework's decorator could then go
away. Deciding that is part of the issue - the rate-limit feature already
carries interval and count, and nothing outside the test suite reads them.

Noticed while adding a rate-limit declaration for OX (interval 300, count
1500), which switched that 0.2-second-per-request delay on for the whole OX test
run.

Lenguaje dominante
Python
Estrellas
412
Forks
113
Merge medio
2 d 18 h
PR fusionados (30 d)
15

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de python-caldav/caldav

Todos los issues de python-caldav/caldav

Issues similares

Más issues de Python

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.