[BUG] Incoming messages' payload are not parsed into objects

[nightknighto]

Describe the bug.

I am trying out generating a template for the example mqtt document . I was testing the subscribe function registerReceiveLightMeasurementMiddleware and it seems that the message's payload is not parsed from string to object, it stays as string. There is also no validation.

I can't also parse it manually either, it will give an error due to it not being a valid JSON object string.

Expected behavior

1- message.payload should be parsed into an object, respecting that the type is specified to object in the asyncapi document. 2- There should be validation for the payload.

Screenshots

How to Reproduce

1- Copy the linked AsyncAPI document to a new folder. 2- Generate a nodejs template from the file. 3- Copy the example script, add to the callback of client.registerReceiveLightMeasurementMiddleware: console.log(typeof message.payload). 4- Try it out, for example: npx mqtt pub -t 'smartylighting/streetlights/1/0/event/101/lighting/measured' -h 'test.mosquitto.org' -m '{"id": 1, "lumens": 3}' 5- It will output string. You also can't use JSON.parse to parse it. There is also no validation to the message, you can send anything.

🖥️ Device Information [optional]

No response

👀 Have you checked for similar open issues?

• [x] I checked and didn't find similar issue

🏢 Have you read the Contributing Guidelines?

• [x] I have read the Contributing Guidelines

Are you willing to work on this issue ?

None

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity :sleeping:

It will be closed in 120 days if no further activity occurs. To unstale this issue, add a comment with a detailed explanation.

There can be many reasons why some specific issue has no activity. The most probable cause is lack of time, not lack of interest. AsyncAPI Initiative is a Linux Foundation project not owned by a single for-profit company. It is a community-driven initiative ruled under open governance model.

Let us figure out together how to push this issue forward. Connect with us through one of many communication channels we established here.

Thank you for your patience :heart:

[batchu5]

I'm working on this

[batchu5]

The bug happens only in Windows.

Linux

https://github.com/user-attachments/assets/724b51da-7e91-4989-b5b0-b819d540141f

Windows

https://github.com/user-attachments/assets/8a510634-76a7-4bdf-8c3f-916bd3404eb2

In Linux, after converting a buffer to a string the payload becomes

'{"lumens": 10}'

but in Windows it becomes

'{lumens : 10}'

which makes the JSON invalid.

This difference is caused by the buffer's content being different.

PowerShell interprets quotes differently when passing arguments: it strips the double quotes inside single quotes when executing the npx command.

I decided to validate and repair the passed JSON, if necessary, before handing it to JSON.parse().

@fmvilas, @derberg, @kaushik-rishi, do you find this approach suitable?

[derberg]

We do not need to proceed with the fix. In next few months this template will be replaced with a new one developed under generator repo

[aeworxet]

Should @batchu5's already coded fix be submitted as a PR anyway so affected users are no longer impacted while they wait for the new version, to ensure the archived code won't contain this bug and that this peculiarity isn't forgotten when developing the next version of the template?

[derberg]

but we are talking about windows here? nobody runs production deployments on windows, and local development can always be workaround with docker. If there is a workaround, I'd prefer not to be distracted and look into a PR that is not necessarily critical

[aeworxet]

Okay. If a similar issue with PowerShell arises again, at least the root cause will be clear in advance.