Bug report

While investigating a failure as part of ros2/geometry2#172, I found out that action servers and clients in the same process may run into a race. If the server immediately sets a goal to "success" or "failed" during the "handle_accept" callback (like here), the entire action may be gone by the time the client goes to get the result (via async_get_result). I was only able to reproduce this particular behavior while using Windows Debug. It's not entirely clear to me if this is a bug, since I'm not sure if it is valid for a server to set the goal to "success" or "fail" during the "handle_accept" callback. Nonetheless, @jacobperron thought it would be a good idea to open a bug to track this.

Required Info:

• Operating System:
  • Windows 10
• Installation type:
  • Source (Debug build - colcon build --merge-install --cmake-args -DCMAKE_BUILD_TYPE=Debug)
• Version or commit hash:
  • b6d18cc
• DDS implementation:
  • Fast-RTPS
• Client library (if applicable):
  • rclcpp

Steps to reproduce issue

Comment out the workaround line here.

Build on Windows in Debug mode:

colcon build --merge-install --event-handlers console_cohesion+ console_package_list+ --cmake-args -DBUILD_TESTING=ON --no-warn-unused-cli -DCMAKE_BUILD_TYPE=Debug -DINSTALL_EXAMPLES=OFF -DSECURITY=ON --packages-up-to tf2_ros tf2_py

Run on Windows in Debug mode (you may have to do this several times to make the issue happen):

colcon test --merge-install --event-handlers console_direct+ --executor sequential --retest-until-pass 10 --packages-select tf2_ros

Expected behavior

Test passes every time.

Actual behavior

Test fails sometimes with "Goal handle is not known to this client"