Page Comparison

...

Guard conditions in rules are usually the best way to ensure idempotence idempotency in rules because they can be used to only take action have an effect when specific conditions are met. 

Unfortunately, there are some functions in KRL (notably in the PCI and (Classic) RSM modules) that make state changes (i.e. have persistent effect). When these are used, they can cause side effects before the rule's guard condition is executed. This is a design flaw in KRL that will be rectified in future versions of the language. These functions should have been actions rather than functions so that they can sit after the guard condition. 

In the meantime, a guard A guard rule offers a useful method for assuring idempotency in rules. The basic idea is to create two rules: one that tests a guard condition and one that carries out the rule's real purpose. 

...

The following is the guard rule for the Fuse initialization (assuming pds is a module providing persistent storage for multiple rule sets):

rule kickoff_new_fuse_instance {
  select when fuse need_fleet
  pre {
    fleet_channel = pds:get_item(common:namespace(),"fleet_channel")
    is_null = fleet_channel.isnull()
    _ = is_null => fleet_channel.klog(">>>>>>>>>>> Not creating new fleet; fleet channel exists: ") | null
  }
  if(is_null) then
  {
    send_directive("requesting new Fuse setup");
  }
  fired {
    raise explicit event "need_new_fleet"
      attributes {
        "_api" : "sky",
        "fleet" : event:attr("fleet") || "My Fleet"
      }
  }
}

...