Skip to content

add timeout arguments elsewhere#1185

Open
fujitatomoya wants to merge 5 commits intorollingfrom
fujitatomoya/add-timeout-arguments-elsewhere
Open

add timeout arguments elsewhere#1185
fujitatomoya wants to merge 5 commits intorollingfrom
fujitatomoya/add-timeout-arguments-elsewhere

Conversation

@fujitatomoya
Copy link
Collaborator

Description

Follow up of #1170, so that we can avoid the hang-up situation described in #1159

Fixes # (issue)

Is this user-facing behavior change?

No, the additional timeout falls back to the current behavior.

Did you use Generative AI?

Yes, Claude Sonnet 4.5

Additional Information

Signed-off-by: Tomoya Fujita <Tomoya.Fujita@sony.com>
Signed-off-by: Tomoya Fujita <Tomoya.Fujita@sony.com>
Signed-off-by: Tomoya Fujita <Tomoya.Fujita@sony.com>
Signed-off-by: Tomoya Fujita <Tomoya.Fujita@sony.com>
Signed-off-by: Tomoya Fujita <Tomoya.Fujita@sony.com>
@fujitatomoya fujitatomoya requested a review from ahcorde February 5, 2026 23:55
@fujitatomoya fujitatomoya self-assigned this Feb 5, 2026
@fujitatomoya
Copy link
Collaborator Author

@araitaiga can you review this?

@fujitatomoya
Copy link
Collaborator Author

Pulls: #1185
Gist: https://gist.githubusercontent.com/fujitatomoya/2d2b948ddb17791c608d79be995d9fd8/raw/6ab0276f54acc2c7437ba4bea269b313011936f4/ros2.repos
BUILD args: --packages-above-and-dependencies ros2action ros2component ros2lifecycle ros2service ros2param
TEST args: --packages-above ros2action ros2component ros2lifecycle ros2service ros2param
ROS Distro: rolling
Job: ci_launcher
ci_launcher ran: https://ci.ros2.org/job/ci_launcher/18138

  • Linux Build Status
  • Linux-aarch64 Build Status
  • Linux-rhel Build Status
  • Windows Build Status

parser.add_argument(
'--include-hidden-nodes', action='store_true',
help='Consider hidden nodes as well')
parser.add_argument(
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would it make sense to add a default timeout for lifecycle get, so that it stays consistent with other multi-node verbs?

ros2 param list and ros2 component list both use a default timeout of 5.0s, since they may query multiple nodes and a single unresponsive node could otherwise block the command indefinitely.

ros2 lifecycle get behaves similarly when the node name is omitted, but --timeout currently has no default value and therefore waits indefinitely.

How about applying a consistent policy where verbs that may query multiple nodes default to 5.0s?

rclpy.spin_until_future_complete(node, future)
rclpy.spin_until_future_complete(node, future, timeout_sec=timeout)
if not future.done():
raise RuntimeError(
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would it be possible to include the node name in timeout error messages for call_get_states (and related functions)?

In this PR, most timeout errors already include the node or service name, but the lifecycle functions (call_get_states, call_change_states) currently do not. This can be confusing for users of call_get_states, since ros2 lifecycle get may query multiple nodes in a loop, making it hard to identify which node was unresponsive when a timeout occurs.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants