ASTController unexpectedly invalidates a valid input

[jefft0]

Use case: In frame 300ms, there is model for a grab command which predicts h attached s in the next frame:

 (fact (pred (fact (mk.val h attached s) 0s:400ms:0us 0s:500ms:0us)))

As usual, a prediction monitor is created for this prediction. Because the preconditions were not met in frame 300ms, the grab command fails

In the next frame 400ms, the preconditions change and now the grab command can succeed. The model for grab command executes, and at the beginning of the next frame (500ms) we have the new fact which is injected by the auto-focus controller.

fact1:(fact (mk.val h attached s) 0s:500ms:0us 0s:600ms:0us)

The auto-focus controller also creates an ASTController to monitor this one fact.

Also in frame 500ms, the prediction monitor for the original prediction fires (at the end of its predicted time interval starting at 400ms). Because the original grab command didn't succeed, it correctly injects the following anti-fact:

anti_fact1:(|fact (mk.val h attached s) 0s:400ms:0us 0s:500ms:0us)

The problem is that when this is injected, it is an input to the ASTController created for fact1 where the following code invalidates all facts which match its value. (In this case, input is anti_fact1 and target_ is the target of the ASTController, fact1.)

switch (input->is_timeless_evidence(target_)) {
case MATCH_SUCCESS_NEGATIVE:
  kill();
  tpx_->signal(v);
  target_->invalidate()
  break;

As the name implies, the method is_timeless_evidence only matches the values, regardless of the time intervals. Even though anti_fact1 is for frame 400ms, this code invalidates fact1 which is for frame 500ms. Any following operations which need it will fail because it has been invalidated.

The ASTController invalidates the fact, which doesn't seem right. But what is an ASTController? Here is the description: "Atomic state controller. Attached to a null-pgm and monitoring to a (repeated) input fact (SYNC_PERIODIC or SYNC_HOLD). Upon catching a counter-evidence, signal the TPX and kill the object (i.e. invalidate and kill views); this will kill the controller and TPX."

A change targeted pattern extractor (CTPX) accumulates inputs over several frames. The ASTController seems to be part of the mechanism to prevent a CTPX from using an input it has already stored if a new input is counter-evidence. That is reasonable. But it doesn't seem right to invalidate the input from being used for other purposes.

I created this issue so that we can discuss solutions. One solution is that the CTPX should store a copy of the input and only that copy is invalidated. Or perhaps the CTPX can be invalidated without invalidating its inputs.