CI:

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

This is ok... if only using rmw_fastrtps_cpp.

Should we consider the case of the server and the client using different vendors?
What would the expectation be in that case?

I am ok with merging this, and addressing the cross-vendor case in a follow-up, but I would like @clalancette opinion first.

atm, i think that is okay not to consider cross-vendor communication and current code does not seem to care about that either. (https://docs.ros.org/en/rolling/Concepts/Intermediate/About-Different-Middleware-Vendors.html#cross-vendor-communication) i understand we necessarily do not want to break that compatibility with this., but rosbag2 service problem

without this uniqueness capability during a single request-reponse pair, it cannot tell which request is mapped to which response, so that rosbag2 cannot know which message needs to play.

is much bigger problem happening right now...

@clalancette @wjwwood what do you think?

i think that is okay not to consider cross-vendor communication

In fact, we would first need to have service interoperability between all the RMWs, which is currently not the case.

Approved, and CI green, so I feel free to merge

Did we run CI on RHEL Debug for this? That was the case that caused all of the problems before.

It looks like not, here is a run. If this fails, we'll have to revert:

• Linux-rhel

All right, all looks happy with this. We'll see what happens overnight.