MQTT Engine bug - custom namespace subscription with retain - engine disconnect from server when receive PUBLISH before SUBACK

Hello,
I’m trying to qualify Ignition for our usage, and we need to use our MQTT Server JoramMQ.
So i’m testing MQTT engine to make the bridge between MQTT and Ignition.
It works very well with sparkplug namespace.
However, when I create a custom namespace, listening to a topic that contains “retain” values, then the connection is broken up every minutes, and it basically break all MQTT features.
Tinkering around, I noticed that the MQTT server is sending the list of retain value before answering the SUBACK, and it’s ok by MQTT 3.1.1 specifications. (cf. L964-965 “The Server is permitted to start sending PUBLISH packets matching the Subscription before the Server sends the SUBACK Packet.”)
When I’m trying a custom namespace without retain, then there is no issue.

So I can only conclude that the MQTT Engine is not handling correctly the possibility to receive PUBLISH packets before receiving the SUBACK.
Did someone has a similar experience ?

Tks
Cyril

@wes0johnson

How is the connection actually being lost? Can you see which end (client or server) is terminating the socket?

Yes I can see the connection is terminated by the client, complaining he hasn’t got a response in time. I’ve confirm from server logs that all response are sent in time, especially the PINGACK
Here is the log from ignition

I notice a couple of things there. I think you may be running an older version of the MQTT Engine module. In the current version, failed subscriptions should result in a disconnect. So, I’d recommend two things. Make sure you are running the latest version of the module. In addition, either disable the namespaces you are not using or ensure in the MQTT Server you have set up ACLs to allow those subscriptions.

Finally, the issue you are seeing may actually be a bug. But, we have to do a bit of work on our side to verify this. In addition, if it is a bug I suspect it may be in the underlying open source MQTT client library we use. But, we’ll dig into it. Regardless, I’d be curious if updating your module and fixing the subscription/ACL issues results in better behavior.