web page publish and main loop share the MQTT send queue
@Yukti007 ya está trabajando en esto.
Desde el 13/10/2026.
Evaluación
Este issue todavía no se ha evaluado.
Descripción
Describe the bug
Messages going to the MQTT broker first go into a small queue of 8 slots. The main program adds messages to it (alarm Acknowledge/Dismiss/Shelve replies and the "online" message). The Broker Console web page also adds messages when someone presses Publish. The web page runs in a separate task that can interrupt the main program at any moment, and there is no lock. Both can pick the same empty slot. Then one message is lost, or a message goes out with one sender's topic and the other sender's text.
Short Summary of the expected behavior:
Every message added to the MQTT queue is sent once, on the right topic, with the right text, no matter which part of the program added it.
Short Summary of the buggy behavior:
If the web page and the main program add a message at the same moment, one message can be lost, or the topic and the text can come from different messages. The web page can still say "published".
To Reproduce
Found by reading the code. Not yet tested on a real Krake board. The two writes must overlap within microseconds, so this is hard to make happen on purpose. Suggested steps to try:
- Connect the Krake to Wi-Fi and an MQTT broker. Subscribe to its ACK topic and to a Broker Console publish topic with an MQTT client.
- Open the Broker Console web page on the Krake.
- Use a script to send many POST requests to
/broker-console/publishvery quickly. - At the same time, send alarms to the Krake and acknowledge them on the knob, or just let the "online" message go out every 10 seconds.
- See error: some messages are missing on the broker, or an ACK-topic message arrives on the Broker Console topic (or the other way round).
Expected behavior
All messages arrive at the broker, each on its own topic with its own text. An operator's Acknowledge is never lost.
Screenshots
None. Not yet tested on hardware.
Hardware description
Model: Krake (GPAD_API firmware), checked against main at commit b6ea4b3 (2026-09-20)
Serial Number: N/A (found by reading the code)
Other: Affects any Krake with Wi-Fi/MQTT and the web page in use.
Test Equipment
Model: N/A (not yet tested)
Serial Number: N/A
Additional context
Where in the code:
- The queue and the function that adds to it:
Firmware/GPAD_API/GPAD_API/mqtt_handler.cpplines 30–55
https://github.com/PubInv/krake/blob/b6ea4b3eaf0e93a580cad7cdc9f8c1541860ff06/Firmware/GPAD_API/GPAD_API/mqtt_handler.cpp#L30-L55 - Sending from the queue (in
loop()):mqtt_handler.cpplines 57–77
https://github.com/PubInv/krake/blob/b6ea4b3eaf0e93a580cad7cdc9f8c1541860ff06/Firmware/GPAD_API/GPAD_API/mqtt_handler.cpp#L57-L77 - The web page handler that adds to the queue (runs in the async web server's task):
GPAD_API.inolines 2175–2225 (thequeueMqttcall is at line 2203)
https://github.com/PubInv/krake/blob/b6ea4b3eaf0e93a580cad7cdc9f8c1541860ff06/Firmware/GPAD_API/GPAD_API/GPAD_API.ino#L2175-L2225 - Main-loop code that adds to the queue:
GPAD_API.inoline 397 ("online" message every 10 seconds) and line 575 ("online" message on broker connect);GPAD_menu.cpplines 63, 78, 92 and 118 (Acknowledge/Dismiss/Shelve/Complete)
https://github.com/PubInv/krake/blob/b6ea4b3eaf0e93a580cad7cdc9f8c1541860ff06/Firmware/GPAD_API/GPAD_API/GPAD_menu.cpp#L63 - The same pattern in the SPI mirror queue, which
queueMqtt()also fills:spi_broker_mirror.cpplines 50–70
https://github.com/PubInv/krake/blob/b6ea4b3eaf0e93a580cad7cdc9f8c1541860ff06/Firmware/GPAD_API/GPAD_API/spi_broker_mirror.cpp#L50-L70
Why it happens: queueMqtt() finds an empty slot, copies in the topic, then the text, and only then marks the slot as used. The web task can interrupt in the middle of that, see the same slot as empty, and write into it too. There is no mutex, critical section or FreeRTOS queue: a search of the firmware for mutex, Semaphore, portENTER_CRITICAL and xQueue finds nothing.
How likely: low. The two writes must overlap within microseconds. But it happens at random, cannot be reproduced on demand, and a lost Acknowledge matters on an alarm device.
Possible fix: protect queueMqtt() and serviceMqttQueue() (and the matching SPI mirror functions) with a FreeRTOS mutex or a short critical section. Or have the web handler pass the message to the main loop through a FreeRTOS queue, so only loop() touches the MQTT queue. The same handler also changes saved publish topics and settings from the web task (lines 2204–2221), so the fix should cover those too.
Not checked: the async web server library is not listed in platformio.ini, so its exact task priority and core setting could not be confirmed from this repo.
Related: #370 (MQTT messages published), #283 (shared global variables).
- Lenguaje dominante
- C++
- Estrellas
- 9
- Forks
- 6
- 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 PubInv/krake
-
USB and COM port share one command bufferPosiblemente ocupada @Yukti007 la tomó hace 10 días. AbiertoHigh Priority regression test type: bug
-
Firmware, Krake Loosing Broker Settings back to a DefaultPosiblemente ocupada @nk25719 la tomó hace 22 días. Abiertotype: bug
-
Hardware, LB0007 Not Playing Alarm FileQuizá libre de nuevo @nk25719 la tomó hace 29 días y no hay ningún pull request abierto. Abierto
-
Mini MP3 File Names and File Order For Reliable Play Back, Both GPAD_API and Factory TestQuizá libre de nuevo @Yukti007 la tomó hace 31 días y no hay ningún pull request abierto. Abiertodocumentation
-
Dificultad 5/5 Más de una semana Aptitud para principiantes 15/100
Todos los issues de PubInv/krake
Issues similares
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 66/100
Los mantenedores suelen responder en 1 día
-
bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 85/100
telegramdesktop/tdesktop#31505 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
Los mantenedores suelen responder en 1 día
-
ll-builder shell completions omit existing lockfile commands and --lockedPosiblemente ocupada @project-nju-learner la tomó hoy. Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 90/100
OpenAtom-Linyaps/linyaps#2291 ·
Los mantenedores suelen responder en 1 día
-
area: ui bug P3: low value: low
Dificultad 1/5 1-3 horas Aptitud para principiantes 85/100
patrick-hudson/put.gd-desktop#494 ·
Los mantenedores suelen responder en 1 día