Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

Handler callback cannot say "consumed" and "stop" separately

Ouverte
  • Quelque chose ne va pas ?
#346 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Personne n'a encore pris cette issue.

Évaluation

Difficulté
5/5
Temps estimé
Plus d'une semaine
Accessibilité débutants
35/100
Type d'issue
Fonctionnalité
Clarté
Plutôt claire
Activité
Active
Stack technique
php
Domaine
backend, distributed-systems

Piste de recherche

Start with the runExisting() and subscribe() callback contracts and trace how adapters use their boolean result; the issue names queue-redis Adapter.php:36 and queue-amqp ExistingMessagesConsumer.php:45 as examples. Compare the graceful shutdown path with run($max) counting, then evaluate how a revised result can preserve both consumption and stop status across the shared contract. Done when handled messages are acknowledged and counted even as the loop stops, while refused messages remain unconsumed.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

The handler callback passed to runExisting() and subscribe() returns one bool, and it is asked to carry two independent facts: whether the message was consumed, and whether the adapter should keep delivering.

They disagree on graceful shutdown. QueueConsumer::handle() processes the message and then returns $this->loop->canContinue():

private function handle(MessageInterface $message): bool
{
    $this->worker->process($message, $this->queueName);
    return $this->loop->canContinue();
}

So when SignalLoop sees SIGTERM, the callback returns false for a message that was handled to completion. Every adapter then keeps it:

The message is processed again on the next run. For a non-idempotent handler — a charge, an email, a webhook — that is a duplicate on every restart, deploy or scale-down, which is when SIGTERM arrives.

run($max) has the same shape: it reports $count messages processed, but the message handled just before the loop stops is not counted, because the early return skips the increment.

Both fall out of the single return value, so they cannot be fixed in a consumer or in an adapter alone. Some options:

  • the callback returns an enum (Consumed, ConsumedAndStop, NotConsumed) instead of a bool,
  • or the adapter asks separately, e.g. the callback stays "was it consumed" and the loop is checked by the adapter through a second callback or a LoopInterface it already holds.

Raised out of #340, which fixes a related case — a message refused before being handled — without touching this one.

Langage dominant
PHP
Étoiles
61
Forks
31
Aucune PR mergée en 30 j

Préparer son environnement

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de yiisoft/queue

Toutes les issues de yiisoft/queue

Issues similaires

Plus d'issues PHP

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.