Computationally (not mathematically) itās an arbitrary choice to evaluate the trigger first and then the required expression for the same event (or the other way around), Iām sorry you canāt see that⦠but yeah letās end this part of the story/argument.
In the end it doesnāt matter that much what your opinion or mine is, there seems to be a breaking change in RM which will affect users like the OP
It's NOT an arbitrary choice which to evaluate first. The Required Expression MUST be evaluated first. If it isn't, then it's not actually a requirement is it?
If there's a situation in which the trigger is processed BEFORE processing the thing that sets the requirements for the trigger, that sorta breaks the whole concept, does it not?
If it's evaluated first, it doesn't really get you the behavior it was created for. The behavior I described above, the behavior that is documented, and the behavior @hubitrep is seeing in 2.3.9 are all (the same and) correct.
Specifically, see the example in the doc that triggers on mode change. This could never work any other way. It's really only a concern when the trigger and required expression refer to the same event. It's the value at the moment just before triggering (or at but before the resulting state is the case) that matters.
For as long as you'll approach the problem this way I'm afraid you won't reach the understanding you're seeking. Sorry.
The designer of this app made this choice, you were presented with evidence of that and of the reasons behind it. I for one did not think through every use case, every edge case to come up with a better design, so I won't speak to it in absolutes. I do leverage this pattern in many rules after having tested it and I am comfortable with it.
Well I rolled all the way back to 2.3.7 to test, and yes, it does trigger for a value of 2 even though the RE is set to <2.
In my eyes, this is wrong. But if I've never noticed it before, then it must not be a problem with any of my rules.
Anyway, I prefer the functionality in 2.4.0 as it seems to be more conforming to proper logic and math. However, it seems I am always on the minority side of things around here so I have decided this is not going to be my hill today. I will die elsewhere.
@bravenel, I'm inferring this bug squash hasn't been released yet since I haven't seen it in the release notes. Assuming this is true, wanted to let you know that I'm seeing a variant of the bug on C7 2.4.0.151 even when two different variables are used across RE and Trigger. See the below example--it doesn't trigger as expected. I've been able to reproduce, but oddly not on my C8. Hope this helps tracking it down.
Hmm you have me doubting myself, so I rebuilt the same rule from scratch for a third time with new hubvars and it still doesn't trigger. Below is my most recent attempt on a C7 along with the Event Subscriptions. FWIW if I do this same thing on my Dev hub (C8), it works as expected.
Correct. After updating rule, I went to Settings/Hub Variables, clicked on current value of variable, and changed it to another value. Rule not triggered.
Well, until you are getting events from Hub Variables, nothing like your rule will work. I don't know what's going on with your hub. You should probably restore a backup. Make a simpler rule with no Required Expression, and see if you get Hub Variable events or not.
Look at Location Events. Hub Variable changes are there:
Turns out the hubvar change does show up under Location Events, but still no RM trigger. When I removed the RE (that had showed as TRUE), however, the hubvar change did trigger the rule successfully.
Hoping this provides more insight in root cause?
EDIT: also played with different REās. When itās not a variable, I get expected behavior. Only REs with a hub variable seem to produce the problem.