In this post-19.2 world, I'm hoping this will be less and less of an issue. But I continue seeing it, and even today I experienced a weird and unexpected issue that was traced down to some previous developer having used load() within an expression rule.
In my case the symptom was something rather subtle this time. A script task was running a few different evaluations on its data outputs to save different values to different PV variables. Two of them are using the same expression rule but slightly different inputs to save what should've been different values into two different PVs. However both PVs were getting the same value upon execution. The first thing I tried was commenting out the earlier one (which was evaluating correctly), and when I did that, the second one worked. When I un-commented the first expression again, again both values evaluated (incorrectly) to the same value.
I then dug into the expression rule that was setting the value. The intricacies aren't important, other than that this expression rule accepted an array of data and a few other parameters and was expected to spit out a username based on passed-in role ID and other things. I noticed that some local variable within the expression rule was being defined with load() for some reason; when I changed this to with(), the issue went away. As an aside, it's interesting that this proves in a sense that separate data outputs in a node share execution in at least some respects, because the value of the load() being run in the first output was accidentally affecting the second one. I've seen such quirks in SAIL forms before, but never in a process model.
I have reproduced this about as simply as is possible:
The above script task is set to save the text "first", "second" and "third" into 3 PVs named accordingly. What do you think will happen? Previously I would have answered this question wrong.
Given what I know about load(), I suppose I shouldn't be too surprised. Though for some reason I always imagined that separate node outputs were executed more separately than this implies.
Moral of the story: in almost all cases you should not use load() in an expression rule. If you have 19.2+, just use a!localVariables now. Otherwise, use with() until/unless you have specific reasons not to.
Discussion posts and replies are publicly visible
I had the same issue a few weeks ago and spent around 2 hours to figure out what was happening, using a!localVaribales is a great solution because does not impact on the original expression rule behavior!
Thanks for bring it up, I will add it to my topics of waring for my coworkers and students.
Mike, thanks a lot. We made this part of our peer review checklist a while ago. While training and coaching all of our Appian Designers using load() and with() in a correct way always was difficult.