I have a couple of rules that assign a string variable to a JSON array from an API call, like this:
Last few days it’s been getting expression evaluation errors or picking the wrong objects from the JSON array.
I changed it to an expression assignment (with the same context variable) and it’s working fine again.
Not a showstopper by any means, but sharing in case anyone else has encountered this issue.
Hi @Maurice_Steinman - thanks for sharing your tips!
Functionally, there shouldn’t be a difference in those two approaches.
The raw Set Variable action directly using a context variable as shown in your first screenshot doesn’t run through the expression parser, so if you were seeing expression evaluation errors in the variable value that makes me wonder if a different rule might have been evaluating an expression and writing to the same variable.
For troubleshooting this kind of issue, there’s a few general recommendations:
Thanks Josh - I did use the Rule Logs to isolate the issues, here’s a snip of the logs with the wrong result (raw set variable on top) and correct result (expression on bottom). I suppose it’s possible that the API (Visual Crossing Weather) has recently changed its API response subtly and now the expression evaluation is more tolerant? At any rate, it’s working solidly now with expression. The rules in question have been working for months up until recently.
Oh, and the expression evaluation error – that was a downstream result of the context variable not updating in one of the rules (I reused the same variable - 1st to get the $context.response.data and then the next step was to evaluate that variable parsing the fields…but since it hadn’t updated with the data from the API call, it didn’t evaluate correctly). So it just seems that the variable didn’t update when using the direct assignment, but did with the expression version.
Ah, thanks for the clarification. It seems like the rule is trying to store an array of objects in a string. The recommended approach for that would be to use an expression and explicitly stringify() the array. Otherwise you’re relying on implicit conversions.
Historically, we’ve supported some form of implicit conversion for unsupported types like objects, arrays of strings, and even arrays of objects. It isn’t something we formally documented, but I have an idea how we can tweak this to better support the legacy implicit conversions. 
Thank you so much Josh! I’ll check all my rules and apply your recommendation where lacking to make sure things keep working as expected.
Thanks again!!
We pushed an update this afternoon which should better match the legacy implicit conversions of complex data types (arrays/objects) for string variables.
