When you try to do an operation with the Math Node and in the ‘expression field’ you pass a string instead of a valid number, it will return ‘null’ as the answer. That is correct and the expected behavior.
However, if you try to use the Conditional Node to compare if the result of the Math Node is equal to ‘null’, it will always say that it’s not null, even when you pass an invalid number to the math node and the answer is clearly ‘null’ when you look at the payload.
It seems like the value we see in the payload is not the real value the variable is assuming. I’ve investigated this behavior and discovered that if, after passing by the Math Node, you pass the payload by a "JSON encode & decode’ or by an empty ‘Function Node’, it starts to behavior like it should and the Conditional Node that compares if it’s ‘null’ evaluates to true.
This problem is easily seen in the attached workflow and seems to only affect ‘null’ values coming from the Math Node (‘null’ values set with the Mutate Node work properly).
What you are experiencing is one of JavaScript’s most well-known “features”: == vs ===, or “Loose Equality” vs “Strict Equality”.
Strict Equality compares both type and value, where Loose Equality does Type Coercion (converts both values to a common type) and then compares them.
In your first conditional node, you have {{decodedWorking.validation}} == null , since {{decodedWorking}} is not on the payload, it is undefined. undefined is a Falsy JavaScript Value, null is as well. So, with loosely testing equality with ==, undefined == null is True because both values are falsy values.
If you do the same with ===, you get:
In your second conditional node, you have {{working.validation}} which is a null value, and are comparing it to null. Just as before, because null is a falsy value, null == null will result in a True path. But, comparing null to itself with === will also result in a True path because null is equal to itself in both type and value.
I would highly recommend that you check out this article or this article as they both go in-depth on the difference between == and ===, as well as Truthy and Falsy values.
Please let me know if this does not answer your concerns.
Thanks for your quick answer. Sorry, my flow misguided you, because it was using {{decodedWorking.validation}} in the first conditional, which is the comparison I should do when the ‘JSON Encode & Decode’ blocks are inserted in the flow. Please, change the first comparison just to {{working.validation}} and you will see the bug I’m talking about. The first conditional will evaluate to false and the second one to true. Later, if you just add the Empty Function Node between the Mutate and the Conditional Node, you will see that both conditionals will correctly evaluate to true.
The problem is not about 'Equality" vs “Strict Equality”. You can even try putting == or === and the same problem will occur (I’ve tested this before). I’m pretty convinced it’s a small bug.
To make it easier to you, I’ve included all the cases I’m talking about in parallel flows, you just have to click the virtual buttons to see the bug (Kelvin will add the flow).
Thanks for your attention and contact me if you need more information.
@Kelvin_Andrade1@Adrian_Franzoi_Mazzo I see what you mean now; I think this has to do with the serialization of JSON for JavaScript values that do not have a direct, corresponding value in JSON. In this case that would be NaN, or "Not a Number", and our casting NaN to null when passing through JSON encoders and the handing of the payload to the Function Node.
That said, I’ve passed this on to the engineering team for further analysis, and I will let you know what they have to say about this - whether it’s a bug or expected behavior. Thank you for bringing it to our attention.
I’m curious, what led you to discovering this issue? Is there a use case you are trying to implement that this is blocking you on? If so, can you describe it? I may be able to offer an alternative.
Thanks for the explanation, @Dylan_Schuster! It is probably this casting of NaN to null that you mentioned.
I discovered this behavior when I tried to do a fast verification if a value informed by the user was a valid number or not. I assume there are more sophisticated ways of doing it, for instance using the ‘Validate Payload’, but I saw a quick way of doing it using the Math node. The idea was just to try to multiply the value received by 2 and if the result was ‘null’, that means the input was not a valid number (for instance ‘1t43.40’).
Then I discovered the issue, but this is not blocking us by any means.
