`InMemoryAdapter` loses the assigned ID between push and consume
Personne n'a encore pris cette issue.
Évaluation
- Difficulté
- 3/5
- Temps estimé
- 1-2 jours
- Accessibilité débutants
- 54/100
Piste de recherche
Read stubs/InMemoryAdapter.php, especially the push() implementation around lines 44–46, and trace how Worker::process() consumes messages. Check the logging middleware described in performance-tuning.md and the related behavior in issue #341. Confirm the adapter retains the assigned ID through consumption, and that the handler’s envelope behavior matches the intended interaction.
Rédigé par le modèle d'indexation à partir du texte de l'issue.
Description
InMemoryAdapter::push() stores the original message and returns the IdEnvelope only to the caller:
$id = count($this->messages) + $this->current;
$this->messages[] = $message; // stubs/InMemoryAdapter.php:44
return new IdEnvelope($message, $id); // stubs/InMemoryAdapter.php:46
So the id exists for whoever called push(), and nowhere else:
push() returned: IdEnvelope id=0
stored in adapter: GenericMessage meta=[]
INFO: Pushed message with message type "probe" to the queue. Assigned ID #0.
INFO: Processing message without ID.
Anything reading the id at consume time gets null for every message that went through this adapter — Worker::process() itself, and the logging middleware the guide suggests in performance-tuning.md. Meanwhile status($id) does answer for that id, so the two halves of the adapter disagree about whether the message has one.
Storing the envelope instead ($this->messages[] = new IdEnvelope($message, $id)) would make them agree, and would make the stub behave like an adapter that persists what it returns.
Note this interacts with #341: once the envelope is what gets stored, the handler starts receiving an IdEnvelope on the in-memory path too, which is the behaviour that issue is about.
- Langage dominant
- PHP
- Étoiles
- 61
- Forks
- 31
- Métriques de merge des PR
- Aucune PR mergée en 30 j
Préparer son environnement
- Aucun Dockerfile ni fichier Docker Compose
- Aucun modèle de pull request
- Lire le guide de contribution
Par où commencer
- Lisez l'issue en entier, puis le guide de contribution du projet.
- Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
- Forkez le dépôt et travaillez sur une branche.
- Ouvrez une pull request qui référence le numéro de l'issue.
Autres issues de yiisoft/queue
-
Difficulté 5/5 Plus d'une semaine Accessibilité débutants 35/100
-
Difficulté 5/5 Plus d'une semaine Accessibilité débutants 35/100
-
Difficulté 4/5 1-2 jours Accessibilité débutants 47/100
-
Difficulté 5/5 Plus d'une semaine Accessibilité débutants 35/100
-
Difficulté 4/5 3-5 jours Accessibilité débutants 45/100
Toutes les issues de yiisoft/queue
Issues similaires
-
sync-en
Difficulté 1/5 1-3 heures Accessibilité débutants 68/100
Les mainteneurs répondent en général sous 4 jours
-
feature request
Difficulté 1/5 Moins d'une heure Accessibilité débutants 88/100
Les mainteneurs répondent en général sous 1 jour
-
Difficulté 2/5 1-3 heures Accessibilité débutants 72/100
Automattic/blocks-engine#2803 ·
Les mainteneurs répondent en général sous 1 jour
-
bug
Difficulté 2/5 1-3 heures Accessibilité débutants 72/100
hestiacp/hestiacp#5798 · 2 commentaires ·
Les mainteneurs répondent en général sous 1 jour
-
Bug Component: HTTP Component: Telemetry
Difficulté 2/5 1-3 heures Accessibilité débutants 74/100