Thank you @colin_mckibben,
I agree that is makes sense that the auto-flattening feature will be reverted as it was causing more harm than good (you don’t always know if the filter will result in just one value, so you still want to iterate over it, even if it ends up containing only one value. Similar thing holds for no results. With an empty array you can still iterate over it, and it will just make no iterations. With a null value, it breaks on an error, requiring workarounds.
Although adding 2 to the length of the strings will make it consistent to the behavior of ISC workflows and consistency is important here, I would argue that the best change here would be to instead make it consistent by subtract 2 from the result of ISC workflows length function. After all, let’s say we do native change detection on the firstname attribute, we notice a firstname changed to Tom, and then we want to send an HTTP request with the length of the firstname, we want to give the number 3, but ISC workflows now gives the number 5. Why would we care amount the number of characters only used for syntax? This was an odd thing to have to tell our client.
Also notice how you would obtain other strange issues as well. With the way you have things implemented now, equations like this one are suddenly no longer true:
($firstname + "." + $lastname).length() == $firstname.length() + 1 + $lastname.length()
Since a defect has been created for this, could you please revert your change when the defect was fixed as well?
See details here:
Kind regards,
Angelo