A solution that stays 'within' the language of Behaviour Trees, so to speak, would be to introduce a while node in your BT. Find a design that works for you, but one solution could be a composite node that always have exactly 2 children.

It will run (and reset and rerun) the first, and, as long is it is not failing, it will also run the second.

This will give the effect of guarding the execution of a sub-tree by some condition (e.g. "there have been no interrupts") that is checked on every tick.

Another BT abstraction that can work is a parallel node, another composite node, that takes any number of children, and run them all, failing when the first child fails, or succeeding when the first child succeeds etc. depending on your concrete use case. In this way, you can race LookForInterrupts with DoLongButInterruptibleAction, and if LookForInterrupts succeed, the entire node is killed.

A solution that stays 'within' the language of Behaviour Trees, so to speak, would be to introduce a while node in your BT. Find a design that works for you, but one solution could be a composite node that always has exactly 2 children.

It will run (and reset and rerun) the first, and, as long is it is not failing, it will also run the second.

This will give the effect of guarding the execution of a sub-tree by some condition (e.g. "there have been no interrupts") that is checked on every tick.

Another BT abstraction that can work is a parallel node, another composite node, that takes any number of children, and run them all, failing when the first child fails, or succeeding when the first child succeeds etc. depending on your concrete use case. In this way, you can race LookForInterrupts with DoLongButInterruptibleAction, and if LookForInterrupts succeed, the entire node is killed.