Simply refactoring the existing tests was enough to actually trigger that bug, but it was mostly
triggered when restarting a read-only task (for which there is now a specific test). The state reader
would be "empty", that is the transition to RUNNING was already read, and therefore the state
update poll would never trigger the start event.
We now initialize a task's orogen state with the last known state of
the component if available. On "new" deployments, this is taken care of
because we get the last state update as new sample on connection (thanks
to the init: true flag). On non-read-only tasks, the beginning of a task is always
configure and start, which is checked with #rtt_state, and then we get state
events on the port during the transition to either STOPPED or RUNNING.
Simply refactoring the existing tests was enough to actually trigger that bug, but it was mostly triggered when restarting a read-only task (for which there is now a specific test). The state reader would be "empty", that is the transition to RUNNING was already read, and therefore the state update poll would never trigger the start event.
We now initialize a task's orogen state with the last known state of the component if available. On "new" deployments, this is taken care of because we get the last state update as new sample on connection (thanks to the
init: trueflag). On non-read-only tasks, the beginning of a task is always configure and start, which is checked with#rtt_state, and then we get state events on the port during the transition to either STOPPED or RUNNING.