Cancel Delayed Actions doesn't work with Delay per mode

[mbudnek]

This seems to be a recent regression. The "Delay per mode" action does not work with the "Cancel Delayed Actions" action anymore.

To reproduce, run the following rule, then toggle the private boolean and run it again. The delayed actions should be cancelled and the "Log" action should never get executed, but it does. The rule also logs a "Multiple simultaneous rule execution error" message.

If the "Delay per mode" is swapped with a simple "Delay" action the rule works as expected.

[Sebastien]

Could you turn on all logging and also add a screenshot of the logs?

[mbudnek]

Here's the log when I follow the reproduction steps I outlined in my first post:

I also took a look in the app status page, and it looks like the issue is that the scheduled job is being created as non-cancellable even though the Delay per mode is marked cancellable. Note that it's scheduled the delayedActs handler rather than the delayedActsCancel handler that's used for cancellable delayed actions:

[Sebastien]

Interesting. Will leave this for @bravenel - also looks to me like a bug…

[bravenel]

How is Private Boolean being set false? How is this rule being triggered? Please show the main rule page, not the Actions page.

[mbudnek]

@bravenel I'm just manually clicking the "Run Actions" button and the toggling the private boolean. The rule in this thread is just a minimal example to reproduce the bug. The actual rule that that made me notice the issue is more complex and has a lot of logic that's not relevant to this issue.

[bravenel]

So, I can't really tell what's going on. You got the error from there being two instances of the rule running at the same time. That could certainly happen from hitting Run Actions twice. A delay embedded in an IF-THEN-ELSE will often lead to this. So part of what might be going on is some sort of race condition between these two instances.

Having said that, I'll look into it a bit further...

[mbudnek]

Yes, there are two overlapping runs in that log, but the second should have cancelled the delayed actions of the first. Here's the log annotated a bit to hopefully make it clearer:

[bravenel]

Found the problem. Fix will be in next release.