`InMemoryAdapter` loses the assigned ID between push and consume
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 3/5
- Tiempo estimado
- 1-2 días
- Aptitud para principiantes
- 54/100
Línea de trabajo
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.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
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.
- Lenguaje dominante
- PHP
- Estrellas
- 61
- Forks
- 31
- Métricas de merge de PR
- Sin PR fusionados en 30 d
Preparar el entorno
- Sin Dockerfile ni archivo de Docker Compose
- Sin plantilla de pull request
- Leer la guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de yiisoft/queue
-
Dificultad 5/5 Más de una semana Aptitud para principiantes 35/100
-
Dificultad 5/5 Más de una semana Aptitud para principiantes 35/100
-
Dificultad 4/5 1-2 días Aptitud para principiantes 47/100
-
Dificultad 5/5 Más de una semana Aptitud para principiantes 35/100
-
Dificultad 4/5 3-5 días Aptitud para principiantes 45/100
Todos los issues de yiisoft/queue
Issues similares
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 62/100
TYPO3BestPractices/tea#2409 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
api-platform/core#8690 ·
Los mantenedores suelen responder en 1 día
-
No Code Attached Yet
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
joomla/joomla-cms#48626 ·
Los mantenedores suelen responder en 1 día
-
enhancement good first issue
Dificultad 2/5 1-3 horas Aptitud para principiantes 70/100
DorsetDigital/silverstripe-schema-manager#26 ·
Los mantenedores suelen responder en 1 día
-
sync-en
Dificultad 1/5 1-3 horas Aptitud para principiantes 68/100
Los mantenedores suelen responder en 4 días