[QST] time comsuming and blocking of lifecycle management.

Nobody has claimed this yet.

Why is so slow of changing lifecycle state of a node.

there is a test log below, from the data, there will cost at less than 4s, to change the state of lifecycle nodes!

```sh
zs@zs-vm-2204:~/zs_ws/ga_ros$ ros2 service call /actuation/change_state lifecycle_msgs/ChangeState "{transition: {id: 1, label: configure}}"
waiting for service to become available...
requester: making request: lifecycle_msgs.srv.ChangeState_Request(transition=lifecycle_msgs.msg.Transition(id=1, label='configure'))

response:
lifecycle_msgs.srv.ChangeState_Response(success=True)

zs@zs-vm-2204:~/zs_ws/ga_ros$ time ros2 service call /actuation/change_state lifecycle_msgs/ChangeState "{transition: {id: 1, label: configure}}"
waiting for service to become available...
requester: making request: lifecycle_msgs.srv.ChangeState_Request(transition=lifecycle_msgs.msg.Transition(id=1, label='configure'))

response:
lifecycle_msgs.srv.ChangeState_Response(success=True)

real 0m2.185s
user 0m0.459s
sys 0m0.086s
zs@zs-vm-2204:~/zs_ws/ga_ros$ time ros2 service call /actuation/change_state lifecycle_msgs/ChangeState "{transition: {id: 1, label: configure}}"
waiting for service to become available...
requester: making request: lifecycle_msgs.srv.ChangeState_Request(transition=lifecycle_msgs.msg.Transition(id=1, label='configure'))

response:
lifecycle_msgs.srv.ChangeState_Response(success=True)

real 0m1.613s
user 0m0.389s
sys 0m0.075s
zs@zs-vm-2204:~/zs_ws/ga_ros$ time ros2 service call /actuation/change_state lifecycle_msgs/ChangeState "{transition: {id: 3, label: activate}}"
requester: making request: lifecycle_msgs.srv.ChangeState_Request(transition=lifecycle_msgs.msg.Transition(id=3, label='activate'))

response:
lifecycle_msgs.srv.ChangeState_Response(success=True)

real 0m0.572s
user 0m0.349s
sys 0m0.094s
zs@zs-vm-2204:~/zs_ws/ga_ros$ time ros2 service call /actuation/change_mode system_modes_msgs/ChangeMode "{mode_name: 'LEFT'}"
requester: making request: system_modes_msgs.srv.ChangeMode_Request(mode_name='LEFT')

response:
system_modes_msgs.srv.ChangeMode_Response(success=True)

real 0m0.815s
user 0m0.590s
sys 0m0.130s
zs@zs-vm-2204:~/zs_ws/ga_ros$ ros2 service call /actuation/change_mode system_modes_msgs/ChangeMode "{mode_name: 'RIGHT'}"
waiting for service to become available...
requester: making request: system_modes_msgs.srv.ChangeMode_Request(mode_name='RIGHT')

response:
system_modes_msgs.srv.ChangeMode_Response(success=True)

zs@zs-vm-2204:~/zs_ws/ga_ros$ time ros2 service call /actuation/change_state lifecycle_msgs/ChangeState "{transition: {id: 1, label: configure}}"
waiting for service to become available...
requester: making request: lifecycle_msgs.srv.ChangeState_Request(transition=lifecycle_msgs.msg.Transition(id=1, label='configure'))

response:
lifecycle_msgs.srv.ChangeState_Response(success=True)

real 0m3.286s
user 0m0.377s
sys 0m0.086s
zs@zs-vm-2204:~/zs_ws/ga_ros$ time ros2 service call /actuation/change_state lifecycle_msgs/ChangeState "{transition: {id: 3, label: activate}}"
waiting for service to become available...
requester: making request: lifecycle_msgs.srv.ChangeState_Request(transition=lifecycle_msgs.msg.Transition(id=3, label='activate'))

response:
lifecycle_msgs.srv.ChangeState_Response(success=True)

real 0m1.851s
user 0m0.608s
sys 0m0.188s
```

I created a similar issue here too https://github.com/ros2/ros2cli/issues/779

Thanks.

Reproduce the reported /actuation/change_state and /actuation/change_mode timings in the system_modes ROS 2 setup, then compare the behavior with the related ros2cli issue 779. The report names no source files or tests; done requires identifying the cause of the multi-second lifecycle delay and providing evidence that the delay is resolved or explained.

Written by the indexing model from the issue text.