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

Bound the batch acquire count because --prefetch-count is unbounded

Cerrado
  • ¿Algo no está bien?
#62 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
Necesita aclaración
Estado de actividad
Activo
Stack tecnológico
python, redis
Área
backend, distributed-systems

Línea de trabajo

Start with the --prefetch-count option, the worker's queue.Queue and acquire call, then trace RedisTaskBackend.acquire through acquire.lua and the README prefetching section. Confirm how the count reaches the queue and Redis script, and use the real redis-server reproduction described in the issue. Done requires a maintainer-selected ceiling to be consistently enforced and documented.

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

Descripción

Deferred from the task-prefetching review (crew run) rather than fixed in that branch, because choosing a ceiling is a maintainer decision.

What

count is unbounded end to end:

  • --prefetch-count accepts any int >= 1 (the only validation is the lower bound), defaulting to 4 × threads
  • it becomes queue.Queue(maxsize=count) and acquire(..., count=count) in the worker
  • RedisTaskBackend.acquire forwards it as ARGV[8], and acquire.lua pops up to that many tasks inside one atomic EVAL

Why it matters

  • one worker can lock the entire backlog under a single lease, starving every other worker until the shared deadline expires, at which point the reaper records the whole batch FAILED with no retry
  • process memory grows with the number of buffered payloads
  • the single-threaded Redis server is blocked for work proportional to count per call (one ZPOPMIN/HGET/cjson/ZADD/HSET pass per task, inside one script execution)

Reproduced against a real redis-server: one call with ARGV[8]=6 moved all six ready tasks to the running set with an identical deadline and one worker id, leaving the ready set empty.

Options

  • cap the effective count at a documented maximum (or at a new dedicated backend option)
  • clamp prefetch_count to the queue's backlog bound, if one exists
  • derive the ceiling from lease_ttl and the expected worst-case task duration, so a buffer cannot outlive its lease

Related: the buffer dwell counts against lease_ttl (the reserve happens at fetch time), so an unbounded buffer also makes false lease expiries more likely. That ceiling is documented in the branch's README section on prefetching.

Lenguaje dominante
Python
Estrellas
21
Forks
2
Merge medio
12 h 38 min
PR fusionados (30 d)
27

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.

Issues similares

Más issues de Python

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.