fix test failures for rclc.

[fujitatomoya]

Description

this PR addresses 2 issues.

• rclcpp::spin_some(Node::SharedPtr) is deprecated in favor of using an executor directly. see https://ci.ros2.org/job/ci_linux-aarch64/20707/clang-tidy/
• test failures due to invalid ROS 2 context when creating guard conditions. this occurred because the executor was being constructed before rclcpp::init() was called and rclcpp::init() was being called unconditionally, causing issues when running multiple tests.

Fixes # (issue)

Is this user-facing behavior change?

No

Did you use Generative AI?

Copilot Claude Sonnet 4.5

Additional Information

[fujitatomoya]

Pulls: #442
Gist: https://gist.githubusercontent.com/fujitatomoya/3df3ccc3575f1ca296db2c60d571c83d/raw/abd6981248937b2f47c96b8f348e9c32df112cb6/ros2.repos
BUILD args: --packages-up-to rclc
TEST args: --packages-select rclc
ROS Distro: rolling
Job: ci_launcher
ci_launcher ran: https://ci.ros2.org/job/ci_launcher/18203

• Linux
• Linux-aarch64
• Linux-rhel
• Windows

[fujitatomoya]

@SuperJappie08 can you review this?

[Copilot]

Pull request overview

This PR fixes test failures in the rclc action client tests by addressing two key issues: replacing the deprecated rclcpp::spin_some(Node::SharedPtr) API with an executor-based approach, and fixing ROS 2 context initialization problems that occurred when running multiple tests sequentially.

Changes:

• Replaced deprecated rclcpp::spin_some() with explicit executor usage
• Added conditional rclcpp::init() check to prevent multiple initialization failures
• Ensured proper cleanup order for rclcpp resources before shutdown

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[fujitatomoya]

i think this has been broke for certain time? but this fixes a couple of problems in my local environment.

[SuperJappie08]

@fujitatomoya, I have some concerns about the rclcpp::Context check.
(See the comment)

However, I don't have much experience with complex testing for rclcpp (and rclc). So I might be a bit too cautious.

[fujitatomoya]

this became much bigger than i expected. but it just replaces rclcpp methods into rclc function for the test. i believe this is good for test integrity for rclc pacakge, and it can avoid the inconsistency between rclcpp and rclc interfaces and behaviors.

[fujitatomoya]

Pulls: #442
Gist: https://gist.githubusercontent.com/fujitatomoya/0e4ec92a000e00b4df93121b9af99d7b/raw/abd6981248937b2f47c96b8f348e9c32df112cb6/ros2.repos
BUILD args: --packages-up-to rclc
TEST args: --packages-select rclc
ROS Distro: rolling
Job: ci_launcher
ci_launcher ran: https://ci.ros2.org/job/ci_launcher/18207

• Linux
• Linux-aarch64
• Linux-rhel
• Windows

[SuperJappie08]

@fujitatomoya, I might have time to review tomorrow.
However, an early remark I want to make is don't forget to update the package.xml and CMakeLists.txt (as I doubt rclcpp(_action) is used in another test)

[fujitatomoya]

test failures due to invalid ROS 2 context when creating guard conditions. this occurred because the executor was being constructed before rclcpp::init() was called and rclcpp::init() was being called unconditionally, causing issues when running multiple tests.

@SuperJappie08 this PR tries to fix rclc action client/server test above, i just found this test could fail sometimes. so there are some other places in the test depend on rclcpp. after all, we should still keep rclcpp until we address all the test codes independent from it.

[fujitatomoya]

rpr jobs complains the following. https://build.ros2.org/job/Rpr__rclc__ubuntu_noble_amd64/41/console

09:00:38 1: Test command: /usr/bin/python3 "-u" "/opt/ros/rolling/share/ament_cmake_test/cmake/run_test.py" "/tmp/ws/test_results/rclc_lifecycle/rclc_lifecycle_test.gtest.xml" "--package-name" "rclc_lifecycle" "--output-file" "/tmp/ws/build_isolated/rclc_lifecycle/ament_cmake_gtest/rclc_lifecycle_test.txt" "--command" "/tmp/ws/build_isolated/rclc_lifecycle/rclc_lifecycle_test" "--gtest_output=xml:/tmp/ws/test_results/rclc_lifecycle/rclc_lifecycle_test.gtest.xml"
09:00:38 1: Working Directory: /tmp/ws/build_isolated/rclc_lifecycle
09:00:38 1: Test timeout computed to be: 60
09:00:38 1: -- run_test.py: invoking following command in '/tmp/ws/build_isolated/rclc_lifecycle':
09:00:38 1:  - /tmp/ws/build_isolated/rclc_lifecycle/rclc_lifecycle_test --gtest_output=xml:/tmp/ws/test_results/rclc_lifecycle/rclc_lifecycle_test.gtest.xml
09:00:38 1: Running main() from /opt/ros/rolling/src/gtest_vendor/src/gtest_main.cc
09:00:38 1: [==========] Running 4 tests from 1 test suite.
09:00:38 1: [----------] Global test environment set-up.
09:00:38 1: [----------] 4 tests from TestRclcLifecycle
09:00:38 1: [ RUN      ] TestRclcLifecycle.lifecycle_node
09:00:38 1: [       OK ] TestRclcLifecycle.lifecycle_node (15 ms)
09:00:38 1: [ RUN      ] TestRclcLifecycle.lifecycle_node_transitions
09:00:38 1: -- run_test.py: return code -11
09:00:38 1: -- run_test.py: generate result file '/tmp/ws/test_results/rclc_lifecycle/rclc_lifecycle_test.gtest.xml' with failed test
09:00:38 1: -- run_test.py: verify result file '/tmp/ws/test_results/rclc_lifecycle/rclc_lifecycle_test.gtest.xml'
09:00:38 1/7 Test #1: rclc_lifecycle_test ..............***Failed    0.21 sec

which is really strange, because this PR only changes rclc test, not rclc_lifecycle. besides, i cannot reproduce this issue. i think using inconsistent APIs rclcpp and rclc leads to this unstable test behavior. at least, what i can say is this rpr job failure is NOT related to this PR. so we are good to go with green CI.

[fujitatomoya]

@JanStaschulat @Carlosespicur @EugenioCollado can you review and merge this since you are maintainers?

[SuperJappie08]

@fujitatomoya, I did some digging, and exit code 11 probably corresponds to RCL_RET_INVALID_ARGUMENT.

Via the following definitions:

1. https://github.com/ros2/rcl/blob/b5297c8c974539be4819fbe547b7f5c1cd38fc81/rcl/include/rcl/types.h#L35
2. https://github.com/ros2/rmw/blob/5cc9dda460cb5002fc69797a9f4e5fb070d9d011/rmw/include/rmw/ret_types.h#L39

Which is caused by a failing check.

I also noticed the following results are not checked in that test:

rclc/rclc_lifecycle/test/test_lifecycle.cpp

Lines 103 to 125 in fe5b792

	rcl_ret_t res = rcl_init_options_init(&init_options, allocator);
	res += rcl_init(0, nullptr, &init_options, &context);
	rcl_node_t my_node = rcl_get_zero_initialized_node();
	rcl_node_options_t node_ops = rcl_node_get_default_options();
	res += rcl_node_init(&my_node, "lifecycle_node", "rclc", &context, &node_ops);
	rcl_clock_t my_clock;
	res += rcl_clock_init(RCL_ROS_TIME, &my_clock, &allocator);
	rclc_lifecycle_node_t lifecycle_node;
	rcl_lifecycle_state_machine_t state_machine = rcl_lifecycle_get_zero_initialized_state_machine();
	res += rclc_make_node_a_lifecycle_node(
	&lifecycle_node,
	&my_node,
	&my_clock,
	&state_machine,
	&allocator,
	false);
	// configure
	res = rclc_lifecycle_change_state(

So, I suspect it might be something wrong with one of those objects, which causes the creation of the next item to fail.

EDIT: After having thought about this some more, I find my explanation partially unlikely, as the test have correctly finished since the lifecycle event patch.

[fujitatomoya]

@SuperJappie08 can you take a look at #444? i think Xpr jobs are expected to fail because it dose not align with current source code.

[fujitatomoya]

at least, full source code build and tests are all green. #442 (comment)