Retry after tick

[renan028]

Description

The RetryUntilSuccessful decorator retries the child on the SAME tick, thus it behaves like an independent tree, instead of forwarding the tick from the root. This behavior was unexpected for me.
For instance, consider the example below:

1. The condition succeeds once and then, on a second tick, it fails.
2. Assume the action below the retry always fails.

I would expect the tree to exit on the second tick with FAILURE, because the condition would fail. However, the tree is stuck forever on the decorator (and blocked there).

I have added a unittest with the behavior I was expecting.

However, maybe this behavior change could affect a lot of users. so maybe we can discuss solutions?

thanks!

[facontidavide]

I am afraid that this is a problem with no easy solution.
The only alternative is to create a different Retry with he behavior you are proposing ("RetryAsync").

See for instance the difference between Sequence and SequenceAsync

In fact, if i accept this, this other code will be broken instead:

[corot]

In fact, if i accept this, this other code will be broken instead:

To my understanding of BT, this PR implements the proper logic for a retry. I was very surprised when I saw that it was not returning RUNNING on failure. That means the decorator is doing ticking by itself instead of just propagating the tick from the root as decorators are supposed to do.

The case you mention will get broken, true, but that's the result of how ReactiveSequence is implemented: it only halts already executed nodes instead of the following ones. If you do the later, there's no problem on having several async nodes in a reactive sequence (so you can disable this check). Moreover, we only need to halt already executed nodes because this condition prevents re-starting succeeded nodes; changing it from

  if (initial_status == NodeStatus::IDLE)

to

if (initial_status != NodeStatus::RUNNING)

solves that.

Getting a bit philosophical (i.e. Plato-mode), all nodes should behave equally, regardless of whether they are async or sync.
These changes we propose (and use) go in that direction.