Hacktoberfest 2026: as issues que os mantenedores marcaram para outubro, abertas e boas para iniciantes. Ver issues do Hacktoberfest

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

Fechada
  • Algo errado?
#62 0 comentários 0 reações 0 responsáveis Ver no GitHub

Mantenedores costumam responder em até 1 dia

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
5/5
Tempo estimado
Mais de uma semana
Facilidade para iniciantes
35/100
Tipo de issue
Funcionalidade
Clareza
Precisa de esclarecimento
Status de atividade
Ativa
Stack de tecnologia
python, redis
Domínio
backend, distributed-systems

Direção de pesquisa

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.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

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.

Linguagem predominante
Python
Estrelas
21
Forks
2
Merge médio
12h 53min
PRs com merge (30d)
27

Preparar o ambiente

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Issues semelhantes

Mais issues de Python

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.