`InMemoryAdapter` loses the assigned ID between push and consume
Dieses Issue hat noch niemand übernommen.
Bewertung
- Schwierigkeit
- 3/5
- Geschätzter Aufwand
- 1-2 Tage
- Anfängerfreundlichkeit
- 54/100
Rechercherichtung
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.
Vom Indexierungsmodell aus dem Issue-Text verfasst.
Beschreibung
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.
- Vorherrschende Sprache
- PHP
- Sterne
- 61
- Forks
- 31
- PR-Merge-Kennzahlen
- Keine gemergten PRs in 30 T.
Entwicklungsumgebung
- Kein Dockerfile und keine Docker-Compose-Datei
- Keine Pull-Request-Vorlage
- Beitragsleitfaden lesen
Erste Schritte
- Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
- Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
- Forken Sie das Repository und arbeiten Sie in einem Branch.
- Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.
Mehr aus yiisoft/queue
-
Schwierigkeit 5/5 Über eine Woche Anfängerfreundlichkeit 35/100
-
Schwierigkeit 5/5 Über eine Woche Anfängerfreundlichkeit 35/100
-
Schwierigkeit 4/5 1-2 Tage Anfängerfreundlichkeit 47/100
-
Schwierigkeit 5/5 Über eine Woche Anfängerfreundlichkeit 35/100
-
Schwierigkeit 4/5 3-5 Tage Anfängerfreundlichkeit 45/100
Ähnliche Issues
-
sync-en
Schwierigkeit 1/5 1-3 Stunden Anfängerfreundlichkeit 68/100
Maintainer antworten meist innerhalb von 4 Tagen
-
Перевод устарел
Schwierigkeit 2/5 Ein halber Tag Anfängerfreundlichkeit 62/100
-
feature request
Schwierigkeit 1/5 Unter einer Stunde Anfängerfreundlichkeit 88/100
Maintainer antworten meist innerhalb von 1 Tag
-
home php
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 62/100
vincent-peugnet/wcms#670 ·
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 62/100
freescout-help-desk/freescout#5731 · 1 Kommentar ·
Maintainer antworten meist innerhalb von 1 Tag