MQTT IN payloads are now parsing as primitive types bool at least, assuming numerics and arrays would too but haven't tested) rather than as strings. Assuming this is due to the new "autodetect JSON payloads" it seems to do? Intended? Meaning, I'm getting true/false instead of "true"/"false", etc.
EXISTING MQTT IN nodes AREN'T doing this, only the ones that are newly created are doing this, introducing an inconsistency.
Do I need to go through and change all my MQTT nodes to explicitly parse to string, or is this a bug? I couldn't find anyone else mentioning it in searches.
Sounds eerily similar to an issue I had on another project a long time ago where I assumed a JSON.parse() only parsed for actual objects, and didn't realize it also happily parsed primitives?
If you check the definition of JSON you will see that it does include primitive types, so, for example, the string "true" is valid JSON representing the Boolean true. So the new behaviour is correct when it does that conversion.
Im assuming that's a "yes, intended behavior" then? I'm fine with that, it just wasn't a change I could find documentation for, and I couldn't figure out why two nodes that looked identical were returning different things.
For the record, then, old nodes don't always select the old deprecated "string or buffer" option when you open their settings, even though that's what they seem to USE still. Instead half the time they are selecting the NEW option still for me which makes them look IDENTICAL to the NEW nodes I'm creating, but are FUNCTIONING differently until I explicitly change them to a different parsing option. I haven't been able to find a commonality between the nodes that DO select the old value by default, vs the ones that don't, just seemed random.
I have already changed over all my nodes to explicit strings to avoid the issue, but imagine whatever bug does that to the settings screen will trip up others in the future.
Unfortunately, no, I've already corrected all of them, and I don't seem to be able to put it back into that state now through the interface. Wild guess, the configuration at one time didn't save a value for the output parsing (null, these were all mostly setup back in 1.x days probably) and while it falls back to the deprecated BEHAVIOR in this case, the UI did NOT handle it and so selects the "default"?
Specifically, this line (and the similar line in the v5 section above it) seems to default to "utf8 string" parsing if the dataType is null (ie, not even defaulting to string or buffer, but actually to explicitly utf8?):
Seems to make sense as its explicitly trying to default it to utf8 here if the config node doesn't have a specified value:
And of course the config UI is bound to the config value (which doesn't exist) so is defaulting to the first one in the list (auto-detect). Well, actually, its explicitly selecting that in the undefined case: