ISC Workflows fails my primary school math test

[angelo_mekenkamp]

Hi all,

Bug short description: $.trigger.input.length() always seem to give a result that is 2 more than the actual length.

Bug long description:
I created this workflow:

The Send Email action sends a mail to me with this in the body:

The word {{$.trigger.input}} consists of exactly {{$.trigger.input.length()}} characters

Compare Numbers has as value 1: $.trigger.input.length()
Compare Numbers has as operator: Equals
Compare Numbers has as value 2: 5

Let’s test this with as input for the workflow {"input": "apple"}

The mail:

Let’s test this with as input for the workflow {"input": "egg"}

The mail:

Kind regards,
Angelo

[tburt (Thomas Burt)]

Defect created. Thank you

[angelo_mekenkamp]

Thank you @tburt, Internal ticket for future reference: PLTWRKFLW-6024

[adamian (Andrei Damian Fekete)]

They are summing up the "s, right?

[angelo_mekenkamp]

That would be my first guess as well, or in the backend they have indicators what the different data actually is, like “s:apple” for a string and “n:123” for a number, or something else, but that would be speculation as we can’t see the code. At the end it does not matter as long as it works

[colin_mckibben]

This has been fixed in the latest release.

Workflows Improvements: Correct string length and support for objects and arrays in inline variables

The Workflows team has just released two updates to the workflow engine. Correct string length Previously, there was an issue in the JSONpath library used by Workflows that always added 2 to the length of a string when using a JSONpath like $.string.length(). This did not affect arrays. A string like “hello” would result in a value of 7 when using the .length() function. This has been fixed in the latest release, and the length function will now return the correct length, which is 5 in the “hel…

[angelo_mekenkamp]

Thank you @colin_mckibben. I checked and can confirm it works in our sandbox environment now!