web page publish and main loop share the MQTT send queue
@Yukti007 がすでに取り組んでいます。
2026年10月13日 から。
評価
この issue はまだ評価されていません。
説明
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).
- 主要言語
- C++
- スター
- 9
- フォーク
- 6
- PR マージ指標
- 30日以内にマージされた PR はありません
環境構築
このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
PubInv/krake のほかの issue
-
USB and COM port share one command buffer対応中かも @Yukti007 が 6 日前に担当しました。 オープンHigh Priority regression test type: bug
-
Firmware, Krake Loosing Broker Settings back to a Default対応中かも @nk25719 が 18 日前に担当しました。 オープンtype: bug
-
Hardware, LB0007 Not Playing Alarm File対応中かも @nk25719 が 25 日前に担当しました。 オープン
-
Mini MP3 File Names and File Order For Reliable Play Back, Both GPAD_API and Factory Test対応中かも @Yukti007 が 27 日前に担当しました。 オープンdocumentation
-
難易度 5/5 1週間以上 初心者へのやさしさ 15/100
似ている issue
-
難易度 2/5 1〜3時間 初心者へのやさしさ 83/100
メンテナーはふだん 1 日以内に返信
-
3.7.6-dev commit 80481ea - files not centered when resolution differs and zoom = "pixel-to-pixel"オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
grizzlypeak3d/DJV#931 ·
-
bug 🔥 pharesee
難易度 2/5 1〜3時間 初心者へのやさしさ 68/100
メンテナーはふだん 1 日以内に返信
-
bug tooling
難易度 2/5 1〜3時間 初心者へのやさしさ 76/100
-
BoundedVector::insert assigns to slots that were never constructed対応中かも @auraseb が今日担当しました。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
philips-software/amp-embedded-infra-lib#1379 ·
メンテナーはふだん 2 日以内に返信