A failing handler aborts the whole run and blocks everything behind it
Ninguém assumiu esta issue ainda.
Avaliação
- Dificuldade
- 4/5
- Tempo estimado
- 1-2 dias
- Facilidade para iniciantes
- 47/100
- Tipo de issue
- Funcionalidade
- Clareza
- Razoavelmente clara
- Status de atividade
- Ativa
- Stack de tecnologia
- php
- Domínio
- backend, distributed-systems
Direção de pesquisa
Read QueueConsumer::run(), QueueConsumer::handle(), and the failure path through Worker::process() and FailureFinalHandler; inspect stubs/InMemoryAdapter.php:53-56 for how failed messages remain queued. Decide how exhausted failures should affect the run, then check that later messages are handled and the failed message has the intended queue behavior.
Escrita pelo modelo de indexação a partir do texto da issue.
Descrição
One message whose handler throws ends QueueConsumer::run() for everything behind it, and the failing message stays in the queue, so the next run stops at the same place.
Three messages, the second one's handler throws:
run #1 THREW MessageFailureException: Processing of message without ID is stopped because of an exception: handler blew up.
handled so far: ["first"]
still queued: ["poison:second","good:third"]
run #2 THREW MessageFailureException: ... (identical)
handled so far: ["first"]
still queued: ["poison:second","good:third"]
third is never processed, and re-running does not help: queue:run exits at the same message every time.
Mechanically: Worker::process() rethrows as MessageFailureException once the failure pipeline is exhausted (FailureFinalHandler rethrows by design), the exception travels through QueueConsumer::handle() and out of InMemoryAdapter::runExisting(), which also skips the unset() for the current message (stubs/InMemoryAdapter.php:53-56).
A failure middleware that swallows or re-pushes avoids this, so there is a way out. But the default for a queue — stop at the first bad message, retry it forever, never reach the rest — seems worth a decision rather than a configuration note.
Per-message isolation in QueueConsumer::run(), where a message that exhausts its failure pipeline is logged and skipped rather than aborting the loop, would bound the damage to the message that caused it.
- Linguagem predominante
- PHP
- Estrelas
- 61
- Forks
- 31
- Métricas de merge de PRs
- Nenhum PR com merge em 30d
Preparar o ambiente
- Sem Dockerfile nem arquivo Docker Compose
- Sem modelo de pull request
- Ler o guia de contribuição
Primeiros passos
- Leia a issue inteira e depois o guia de contribuição do projeto.
- Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
- Faça um fork do repositório e trabalhe em uma branch.
- Abra um pull request que referencie o número da issue.
Mais de yiisoft/queue
-
Dificuldade 5/5 Mais de uma semana Facilidade para iniciantes 35/100
-
Dificuldade 5/5 Mais de uma semana Facilidade para iniciantes 35/100
-
Dificuldade 3/5 1-2 dias Facilidade para iniciantes 54/100
-
Dificuldade 5/5 Mais de uma semana Facilidade para iniciantes 35/100
-
Dificuldade 4/5 3-5 dias Facilidade para iniciantes 45/100
Todas as issues de yiisoft/queue
Issues semelhantes
-
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 78/100
-
Featured image not passed to checks in the Tasks column or publish blocksTalvez já em andamento @roborourke assumiu hoje. Aberta
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 78/100
humanmade/publication-checklist#100 ·
Mantenedores costumam responder em até 1 dia
-
bug customer-reported
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 62/100
MagnaCapax/PMSS#1072 ·
Mantenedores costumam responder em até 5 dias
-
Dificuldade 2/5 Meio dia Facilidade para iniciantes 68/100
components-web-app/docs#244 ·
-
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 64/100
getgrav/grav-plugin-api#60 ·