The sequence of events is something like this:

-Guard condition becomes true -Rule fires, creating token A -Solver decides A -More planning happens, in which a resource token B is created and, separately, a path between the temporal variable of B and some variable in the guard that created A is created in the constraint network. -The Solver executes a threat decision point, placing a temporal constraint on B. -The Solver un-does the decision point, deleting the constraint. -The constraint engine then calls relax() on every variable reachable from B's temporal variable, one of which is in the guard that created A -When the guard is relaxed, the condition is no longer simply true, so the rule is undone, which causes A to get deleted while it's still on the decision stack.

There are two components to a fix: 1) specified variables maybe shouldn't pass on relaxation messages when they have no effect (poss. true for all variables?) 2) rules should only fire/un-fire after propagation is complete, then cause re-propagation.

Fixed in r6032 by adding post-propagation callbacks to the ConstraintEngine which are invoked after propagation is complete but before the message that propagation is complete has been issued, potentially causing more propagation.