Recursion for expression rules means that the condition in a rule is created either by an action in the same rule or by an action in another rule in a sequence, thus causing that rule to run over and over again, potentially in an infinite loop. When it detects recursion, the Platform disables the expression rule whose condition is repeatedly being evaluated and recreated. In addition, if a rule creates a message that causes a sequence of other rules to be evaluated, which eventually cause the first rule to be evaluated again, then the Platform will disable that first rule in the sequence.
Note: Recursion detection is performed by an expression rules monitor that can be enabled and configured by your Platform administrator. If this monitor is disabled, the Platform will NOT detect recursion nor will it disable expression rules automatically.
When the Platform disables an expression rule, you can see that this
has occurred by the presence of the violation icon (
)
in the Enabled column for the expression rule in the View
and manage expression rules page. You will also find an audit record
about disabling the rule due to recursion in the Audit Log for the Platform.
The Platform also notifies the Platform administrator and the user who
last modified the recursive rule. This last user may be but is not necessarily
the owner (creator) of the rule.
If an expression rule that is recursive is configured for a state within a state machine, this icon appears in the Enabled column for the state machine in the View and manage state machines page and in the States pane in the Configure the state machine page. To edit the expression rule so that it no longer causes recursion, click this icon.
To fix recursion, anyone with access to the rule can change it and re-enable it. If you attempt to re-enable the rule without fixing it or after putting in a fix that does not eliminate the recursion, the Platform will disable the rule again.
AlarmRule_10 determines if Alarm_10 has a severity of 50. If this condition evaluates to true, AlarmRule_10 creates another alarm, Alarm_10 with a severity of 50. This action of creating another alarm of the same name and severity causes the same rule to run over and over again, in an infinite loop. To correct the problem you could rename the alarm that is created by the action.
AlarmRule_20 determines if Alarm_20 has a severity of 100, and if true, it creates Alarm_30 of severity 200. AlarmRule_30 determines if Alarm_30 has a severity of 200, and if true, it creates Alarm_40, with severity 300. Finally, AlarmRule_40 determines if Alarm_40 has a severity of 300, and, if true, creates Alarm_20, with a severity of 100. In this sequence, AlarmRule_20 causes AlarmRule_30 to run, which causes AlarmRule_40 to run, which causes AlarmRule_20 to run again. This sequence of rules is recursive. When it detects this recursion, the Platform will disable AlarmRule_20 but NOT AlarmRule_30 or AlarmRule_40.
To correct the recursion here, you could change the action for AlarmRule_40 so that it does not cause AlarmRule_20 to run again.