Incompatibility with nested action client/servers

[jmblixt3]

Bug report

Required Info:

• Operating System:
  • Ubuntu 24.04 (devcontainer)
• Installation type:
  • From source
• Version or commit hash:
  • rolling, 43198cbfe11c84480b15478f76d5fa3e998e5039
  • (First noticed issue on humble, MRE written for rolling)
• DDS implementation:
  • fast dds
• Client library (if applicable):
  • rclcpp, rclpy

Steps to reproduce issue

Utilizing demos repo with action tutorials_py and action_tutorials_cpp code Apply the following patch (its in a txt file because github issues don't like patches for some reason) patch

Then build and run the following nodes in separate terminals

ros2 run action_tutorials_py fibonacci_action_server

or

ros2 run action_tutorials_cpp fibonacci_action_server

and

ros2 run action_tutorials_py fibonacci_action_hybrid

Finally, run

ros2 action send_goal /some_action action_tutorials_interfaces/action/Fibonacci

Then run it again

ros2 action send_goal /some_action action_tutorials_interfaces/action/Fibonacci

Expected behavior

On the first execution of ros2 action send_goal we get the expected behavior of

Waiting for an action server to become available...
Sending goal:
     order: 0

Goal accepted with ID: 16988b561e414d82bc9fb1c793788156

Result:
    sequence:
- 0
- 1

Goal finished with status: SUCCEEDED

And any subsequent calls to send_goals to some_action work exactly the same only varying Goal ID

Actual behavior

Any Subsequent calls actually result in

Waiting for an action server to become available...
Sending goal:
     order: 0

^C

So the goal request is never processed by the action hybrid, after the first call.

Additional information

I initially found this when working on #1123, thinking there was a race condition within rclpy, but since the goal request is never getting received by the hybrid action. The default goal request processing is a simple return accepted leaving no place for potential race condition issues in that instance.