Geoffrey Biggs

Even if services can't be played back, there is value for debugging tools and inspection tools in at least logging them (assuming the response can also be captured).

> It appears to me that there could be many reasons that a server stops the execution of a goal, and we certainly can't be expected to capture specific cases...

> for out robot products, preempt actually happens much more than abort This makes me want to know: are you preempting goals a lot, or is it that you want...

> From the long posts, what I'm still getting from it is a general agreement on the done() proposal, as long as the result / goal codes add preempt to...

I am against having a user defined return code _if_ there is only one "finished" state. It would make it hard for tools to know in a generic way whether...

An action server is free to cancel a currently-executing goal if it wants to. What is lacking is the ability to report to clients that a goal was cancelled _because_...

I think that directly managing system processes via `ros2` is a dangerous game. Trying to interact with running nodes via the `ros2 node` command is more reasonable, but probably when...

That is the way I would go about it, yes.

> One issue is it has the bridge always accepting goals from ROS 2 action clients before contacting the ROS 1 action server, but that hides what's happening on the...

*If* we decide to adopt the dual approach proposed by @thomas-moulard, then giving every node a UUID, with the option of manually specifying it and potentially using a different type...