Interestingly enough, this test as-is fails for rmw_cyclonedds_cpp. It cannot handle the RMW_DEFAULT_DOMAIN_ID and fails with:

[rmw_cyclonedds_cpp]: rmw_create_node: domain id out of range

It appears we didn't notice before because rcl_get_default_domain_id() implementation will always force the domain id to 0 if no ROS_DOMAIN_ID env var is present or it if contains anything other than a number (because of strtoul use).

Shall we change RMW_DEFAULT_DOMAIN_ID to reflect that? Or should it be honored?

just my 2cts, but why do we need a dedicated package for this? Can't this be part of system tests?

just my 2cts, but why do we need a dedicated package for this? Can't this be part of system tests?

This package is not meant to include system tests, but (ideally) unit tests for every portion of the documented rmw API.

While much of rmw's functionality, as well as rcl's, rclpy's and rclcpp's, is indirectly covered by integration and system tests up the stack, many corner cases cannot be easily (or even at all) checked. The fact that by writing the simplest test case I could come up with already uncovered a bug is at least promising.

I think having a way to let the middleware pick the default is useful, so maybe we should change it so it is honored.

About this. Seems like neither rmw_fastrtps_cpp nor rmw_connext_cpp are doing anything with it. They just pass along whatever ID it came their way. rmw_cyclonedds_cpp is more opinionated and has specific code to reject such default. Assuming we still want that freedom for rmw implementation authors, I'll send PRs to those implementation forcing the domain ID to 0 if the default is given.

CI up to rcl and test_rmw_implementation against all RMW implementations:

• Linux
• Linux-aarch64
• macOS
• Windows

I was missing one last bit! See 7fde494.

@hidmic please follow up with releases as necessary to make this job pass again: http://build.ros2.org/job/Rdev__rmw_implementation__ubuntu_focal_amd64/2/testReport/

Looks like this PR caused two CI jobs to fail last night. I think the fix is just to add a <test_depend> for ament_cmake_gtest. Opening a PR to try that now.

• http://build.ros2.org/job/Fci__nightly-connext_ubuntu_focal_amd64/148/console
• http://build.ros2.org/job/Fci__nightly-cyclonedds_ubuntu_focal_amd64/150/console