Only the first MQTT command from multiple-commands WebSocket packet is handled

[alexanderko]

Describe the bug NanoMQ handles only first command from WebSocket packet containing several MQTT commands.

Expected behavior NanoMQ to handle all MQTT commands transmitted in single WebSocket packet.

Actual Behavior It looks like sequential commands sent to MQTT.js client on a Browser over WebSocket connection go into single WebSocket packet. NanoMQ handles only first command from this WS packet and ignores the rest. Confirmed with version nanomq-0.22.1-windows-x86_64 running on Windows Server 2016.

To Reproduce Can be reproduced from the browser having MQTTjs connection available with the following code

([1, 2, 3]).forEach(id => client.publish("test-topic", ""+id))

Or no-loop equivalent

client.publish('test-topic', '1');
client.publish('test-topic', '2');
client.publish('test-topic', '3');

This produces the next WebSocket packet.

The client subscribed to topic test-topic will receive only first message from the series.

This issue can be reproduced only in a Browser. Broker will handle all messages having the same snippet running in Node.js. I suppose because Node.js uses external ws package to work with WebSocket and this implementation flushes every message into individual WS packet.

Environment Details

• NanoMQ version: nanomq-0.22.1-windows-x86_64
• Operating system and version: Windows Server 2016
• Compiler and language used:
• testing scenario

Client SDK JavaScript, mqtt.js client library

Additional context Similar issue was started here with my comment add in the end of discussion. https://github.com/nanomq/nanomq/issues/1802

[JaylinYu]

I am not a front-end developer... gonna need more help on reproducing this issue. like a html+js client.. but as long as all publish msg are reaching the broker side, it shall be fine. debug level of broker log, or packet-capture also gonna help.

[andriisly]

@JaylinYu, Got it. We will create a test stand that reproduces our issue and get back to you later

[JaylinYu]

Appreciated

[andriisly]

Hi @JaylinYu,

We decided to run NanoMQ in Docker, but unfortunately the defect still reproduces. I’ve prepared a minimal reproduction for the multi-command WebSocket issue. You can find the test stand here: https://github.com/andriisly/nanomq-multicmd-test

It includes:

• nanomq.conf with TCP (1883) and WebSocket (8083) listeners and debug logging
• index.html test page with “Connect” and “Send 3 Messages” buttons
• Detailed README.md with reproduction steps and expected output

Please let me know if you need any additional information or encounter any issues - happy to help!

[JaylinYu]

Thank you for creating a reproduction dashboard for me. I didn't expect a sticky packet issue in mqtt.js, and NNG websocket implementation is really a mess...

I have update it to be compatible with multiple message encapsulation cases. But I would like to verify on another scenario as well, can you mix msg with qos 0/1/2 together, or let me set each msg correspondingly?

[andriisly]

Great, thanks for the update! I’ll extend the test stand to send three messages with mixed QoS levels (0, 1, and 2) in the same WebSocket frame. Once that’s ready, I’ll push the changes and ping you here for verification

[JaylinYu]

Good, and you can have a try on the updated master branch first, also verify by yourself

[andriisly]

Hi @JaylinYu,

I’ve just completed testing against the updated master branch and everything looks good - NanoMQ now correctly decodes and handles all three messages in a single WebSocket frame, even when they use mixed QoS levels (0, 1, and 2). The broker logs show three separate decode_pub_message entries for each payload, and I didn’t observe any drops or mis-orders.

I’ve pushed the updated test stand (with mixed-QoS support) to the repo here: https://github.com/andriisly/nanomq-multicmd-test

Feel free to clone and run it yourself to confirm.

One question: do you have an ETA for when the official emqx/nanomq:latest-full Docker image will be rebuilt to include this WebSocket multi-command fix?

[JaylinYu]

Great, Then I gonna close the issue. I will publish a new release once I confirm the QoS ack procedure. Expected not to be late than next week.

[JaylinYu]

Seeing misorder qos msg in your testing dashboard, but I can confirm that the broker is sending out msg in sequence from Wireshark. Perhaps the client side handles ack at a different rate with nanomq.