Try it with a stand-alone delay before setting PB to true, and make setting PB to true the last action of the rule. I don't have a clue what is going on.
Show me the Settings (App Status page) for the rule that start with the letter p.
Also note that I have other rules that delay setting the PB to true (one w/30 min delay), and they aren’t having the same issue.
Like I said, it makes no sense at all. There is nothing I can see about your rule or the code that runs for it that would explain the failure. No one else has ever reported anything like this either. So, it is for now a mystery.
Since the app ends with the private variable false and then ten seconds later (after the app exits) the private variable is set to true, could there be a race condition on the evaluation of the required expression?
Just a thought.
I like to be unique. The separate delay workaround solves the issue, so fine to go with this. Thanks for your help solving.
Something that caught my attention :
The two delayed actions get queued (and later executed) one right after the other, so the delayed action feature is non-blocking, which surprised me (I tend to use explicit Delay() actions myself). Perhaps this important difference should be mentioned in the docs?
@bravenel I imagine RM is designed to wait for all delayed actions to be completed for the rule to be allowed to exit, given these are the last two actions in the rule? EDIT: of course it is, sorry.
Yeah, delays on actions like this "queue in the background" and the rule proceeds. If you do a delay or an inline "wait for event (e.g. elapsed time)," this delays the rule at this point before proceeding with the remainder of the rule. Most of it is covered in the documentation linked below, but I agree it could be clearer in the 2nd paragraph under Delay that a delay placed directly on an action will allow the rule to continue.
1 Like
This has been clarified, thanks! The behavior described above is indeed intentional. It should also be noted (among users; it is in the docs) that an "Exit Rule" does not affect any delays, waits, etc.
3 Likes
No, this is not how any of this works. Any exit of the rule is an end of an execution thread. At the OS level there is no difference between a rule completing all of its actions and any delay or wait. The functional difference is that a delay creates a scheduled job, which starts up the rule again, most likely with an index passed so that the rule resumes where it should.
The documentation notwithstanding, this difference is not germane to the issue in this thread. Delays of any kind create a scheduled job that will run later. A stand-alone Delay Actions causes the rule to exit, while the delay on an action does not. In either case, the issue that arose came later, after the delay, when the rule executed the delayed action(s). The mystery in this case is why the Required Expression became false right after Private Boolean was set to true.
1 Like
Thank you for the detailed explanation.
@bravenel - FYI, another one of my apps with a delayed private boolean started exhibiting this behavior.
And it wasn't before? If so, that sounds like a possible database problem. Rules don't just change what they do unless the underlying conditions have changed. Have you done a Soft Reset / Restore at any time recently, since these issues showed up?
I haven't, but I will now since it looks like it's a more widespread problem than just that one app.
