Topic name validation: issue with names containing "//" (Cloud Subscriber)

[spulci]

Describe the bug Let Kura establish an MQTT connection as a Cloud Subscriber to a Topic having this kind of name:

a/b//d

Received Payload will not trigger a wiregraph component. No msg will be available on the log.

To Reproduce

1. Create a Cloud Connection with a Cloud Subscriber pointing to an MQTT Broker
2. Define the topic inside Kura as a valid one on your broker. Be sure that a valid topic name contains two subsequent "/" as reported in this bug description
3. Establish a connection to the broker
4. Add a couple of nodes to a Wiregraph: Cloud Subscriber Listener triggered by the connection at step 1; its output goes into a Logger node
5. Start sending an MQTT packet to the topic (simulate it with mosquitto if needed)
6. The logger component will not be triggered

Expected behavior

You should see the payload in the log file (Logger node has been triggered in the wiregraph)

Target Environment (please complete the following information):

• Kura 4.1.3 (emulated or on a Raspberry) and 5.x

Additional context

Could it be connected to this bug in Paho MQTT?

https://github.com/eclipse/paho.mqtt.java/issues/718

[MMaiero]

Hello, you can try to update the Paho version embedded in Kura to see if that solves the issue.

Best regards, Matteo

[spulci]

Hello, you can try to update the Paho version embedded in Kura to see if that solves the issue.

Best regards, Matteo

Matteo,

I tried to replace the embedded Paho version updating to 1.2.5. Issue is fixed.

Do you want me to open a PR to propose the fix?

[MMaiero]

It would be great! Thanks

[spulci]

I've got a feature branch on my fork with the proposed set of fixes. I've started from tag version 4.1.3 since I've only tested it with 4.1.3 (I'm using this version, not the latest 5.x one). Should your target branch in my PR be release-4.1.0? Is this branch a protected one to allow merging for future releases (like a potential 4.1.4)?

Thanks for your help, I want to make a pull request that takes care of all your contributions rule before any code review. I may have some more tech questions I will put inside the PR.

[MMaiero]

Usually changes are done in develop and then back ported (we have a label for that that triggers a GitHub action). So, no manual work should be needed for the back port.

[spulci]

Usually changes are done in develop and then back ported (we have a label for that that triggers a GitHub action). So, no manual work should be needed for the back port.

This sounds great.....I will have to make my changes on a feature branch coming from develop.....I should have a few hours to test this on the develop branch that as far as I could understand is aligned to the latest majord version development (future Kura 5.x).