But it is. Look at the error at time stamp 2024-07-28 11:12:43.995 AM in both screenshots.
There is no time stamp for the rule screenshot. There is no action to delay 5 seconds in the rule you posted, but that's coming from 585 per your logs. Look, trying to help, but not possible to.
I appreciate you assistance. The app does call the actions in another rule that DOES have a delay 5 seconds. Could the log be identifying the rule that triggered the action?
That's 585, and it's the one with the error, not the one you posted. It too has the problem of embedded delay in IF-THEN block, and it did not have the option to Ignore Trigger Events While Running. That's what the other posters were trying to determine, but were misled by what you posted. That option won't help this rule.
I see my error. Thank you for sticking this out. However, app 585, while it has the toggle for Ignore Trigger Events While Running off, it also has no triggers. I didn't think the toggle would have any effect since its actions are being called from another app.
Yeah, this is right. However, it's the actions running multiple times simultaneously that is the source of the problem. The app has no way to know that it's been invoked multiple simultaneous times, which can happen during the delay period when the rule isn't even running (scheduled job invokes the app when the delay ends, picking up where it should).
This particular error is happening as the app's state gets corrupted by a second instance going into the IF-THEN block (or coming out of it) while the first instance is delayed within the same IF-THEN block.
1 Like
Thank you. This helps.
This entire problem arises in the first place due to RM allowing nested IF-THEN actions. Were it not for that, it wouldn't arise at all. But, keeping track of the nesting is necessary when it's allowed, and that means of 'keeping track' is what gets corrupted by the second instance.
Food for thought (for myself), can RM detect that there is no nesting of IF-THENs, and if not dispense with keeping track of the nesting, and hence not encounter this particular problem in that case? If that could be done, then the rules in this topic would work fine. I'll take a look at that. If we could isolate this problem to only those cases with nested IF-THEN, that would be an improvement.
Update: Initial testing of this idea is positive; this improvement will make its way into the next release (2.4.0).
8 Likes
Are you suggesting that recoding nested IF-THEN into logically equivalent linear IF-THEN-ESLEIF would eliminate the problem (albeit with possibly harder to understand coding?)
That makes sense. I've rewritten the rules breaking up the actions into separate rules. I've found that through Required Expressions, conditions and triggers, I can often have actions with no rules. This significantly decreased my log entries as well.
Once this change is made, yes. After the change, only nested IF-THEN with embedded delays would be problematic.
1 Like
