Add in a test for unbounded serialized take.#592
Conversation
This is actually handled differently in rmw_fastrtps_cpp now, so we should have a separate test for it. Signed-off-by: Chris Lalancette <clalancette@gmail.com>
|
Here is CI with this and all of the other PRs listed here:
|
|
Here's another build with the updates in place:
|
|
I think the CI for Windows failure is a red herring (get it?). The one failing test is test_play_publish_clock__rmw_fastrtps_cpp . That test expects publish-to-publish latency to be 7.5ms, but that seems like far too short a gap to reliably get on Windows. It actually saw 9ms, which seems within reason, so I think this is a bug in the rosbag2 tests. The rest of the test failures also seem like Windows-specific issues unrelated to this change. It is a FAILURE rather than UNSTABLE because I think ros2/launch_ros#540 is incorrect for pytest 7 (which is what Windows is still on). We can address that separately. I'm tempted to merge this series in as-is, but I'll want consent on it because these Windows failures look problematic. |
|
OK, after discussion, the consensus is to merge these in and then deal with the rest of the Windows fallout separately. So going ahead and merging in. |
|
@Mergifyio backport lyrical |
✅ Backports have been createdDetails
|
2 participants
Description
We already had a test for serialized_take, but it was only a simple type. Unbounded types are handled differently in rmw_fastrtps_cpp now, so we should have a separate test for it.
This will go along with a series of fixes to rmw_fastrtps_cpp
Is this user-facing behavior change?
No.
Did you use Generative AI?
Yes, I used Claude Opus 4.7
Additional Information
This should be merged after ros2/rmw_fastrtps#880 , ros2/rmw_fastrtps#879 , and ros2/rmw_fastrtps#881 .
This should be backported to Lyrical.