From Tom's review on #4096: #4096 (comment)
There are two ways execution status advances today. The joint trajectory task is polled lazily: ManipulationModule.get_state() calls _refresh_execution_status(), which polls once only when someone asks, and in practice that someone is the visualizer. Whole-body runs added in #4096 also run a watchdog thread that polls on an interval, but only when a planar-base leg exists.
The watchdog is not there for reporting. With two legs, a poll is the only thing that notices one leg aborted and cancels the other, so under the lazy model an arm fault with nobody calling get_state() leaves the base driving. Unifying downward would lose that. Unifying upward would put a thread and RPC traffic on the arm-only path that nothing asked for.
The unification that removes both models is the one already sketched as a follow-up to #3610: give each trajectory an id and publish a TrajectoryStatus output stream carrying accepted, rejected, executing and completed per id. The execution manager then reacts to status instead of polling for it, the watchdog goes away, PlanExecutionManager._poll and its run-id guard go away, and the RPC reply stops being the only way to learn an outcome. Per-id status also fixes the shared status scalars that the #3610 review flagged, where concurrent per-joint motions share one _state and one _last_elapsed.
From Tom's review on #4096: #4096 (comment)
There are two ways execution status advances today. The joint trajectory task is polled lazily:
ManipulationModule.get_state()calls_refresh_execution_status(), which polls once only when someone asks, and in practice that someone is the visualizer. Whole-body runs added in #4096 also run a watchdog thread that polls on an interval, but only when a planar-base leg exists.The watchdog is not there for reporting. With two legs, a poll is the only thing that notices one leg aborted and cancels the other, so under the lazy model an arm fault with nobody calling
get_state()leaves the base driving. Unifying downward would lose that. Unifying upward would put a thread and RPC traffic on the arm-only path that nothing asked for.The unification that removes both models is the one already sketched as a follow-up to #3610: give each trajectory an id and publish a
TrajectoryStatusoutput stream carrying accepted, rejected, executing and completed per id. The execution manager then reacts to status instead of polling for it, the watchdog goes away,PlanExecutionManager._polland its run-id guard go away, and the RPC reply stops being the only way to learn an outcome. Per-id status also fixes the shared status scalars that the #3610 review flagged, where concurrent per-joint motions share one_stateand one_last_elapsed.