Inserted fact not available for next rule

[psantann]

I have a sequence of rules as below. Even though I'm inserting a new AlarmFact and I can see it was created with the proper name, the next rule "We got a new alarm" is still executed so I end up with two AlarmFacts one with count=2 and another with count=1

rule "Process an incoming alarm":
agenda-group "process alarm 1"
when:
$alarm := Alarm()
then:
log("We got an alarm with name {0}".format($alarm.name))
attribute current_alarm_name = $alarm.name
forget $alarm

rule "We got an alarm already existent":
agenda-group "process alarm 2"
when:
$alarm_fact := AlarmFact( name == current_alarm_name)
then:
log("We got another alarm with name {0}".format($alarm_fact.name))
modify $alarm_fact:
count = $alarm_fact.count + 1

rule "We got a new alarm":
agenda-group "process alarm 3"
when:
not exists $alarm_fact := AlarmFact( name == current_alarm_name)
then:
log("We got a new alarm with name {0}".format(current_alarm_name))
insert AlarmFact(current_alarm_name)

[psantann]

The problem seems to be that a "not" before an exists does not apply to the whole expression:
DEBUG:intellect:intellect.Node.When :: Filter using the following list comprehension: matches = [fact for fact in policy.intellect.knowledge if reflection.is_instance(fact, klazz) and not (fact.name == current_alarm_name)]
So if I have another AlarmFact with the attribute name set to something different, it will evaluate the when clause to True and add one more instance of AlarmFact.

[Prockoleck]

The double-fire is agenda-group sequencing leaking state. A fact you insert mid-session isn't visible to the next group, so both rules run and you end up with two AlarmFacts.

The fix is a deterministic engine. One pass, rules sorted by priority, first match wins. That's the design of Rulesmith, which I've been maintaining after hitting this exact thing. Rules in YAML, every evaluation writes an audit line, so you can trace which rule matched and why.