get_publishers_info_by_topic does not return qos depth for publishers with fastDDS

[eschembor-irobot]

Bug report

Required Info:

• Operating System:
  • Ubuntu 20.04
• Installation type:
  • From source
• Version or commit hash:
  • 5EBF27D810C6AB68EEF7D42937CD421D85E50509AE96883239979A1B3A2F4F82
• DDS implementation:
  • fastDDS
• Client library (if applicable):
  • rclcpp

Steps to reproduce issue

Noticed this when using foxglove_bridge. They compute the qos depth to use for a subscriber by summing the qos depths of all publishers on that topic. This is not working with fastDDS as get_publishers_info_by_topic reports a qos depth of 0 for any publisher.

Tracing this through the code, I see the comment here which I think indicates the source of the issue

rmw_fastrtps/rmw_fastrtps_shared_cpp/include/rmw_fastrtps_shared_cpp/qos.hpp

Line 129 in 901339f

* Since WriterQos or ReaderQos do not have information about history and depth,

Expected behavior

I would expect get_publishers_info_by_topic to report the actual qos depth of publishers

Actual behavior

get_publishers_info_by_topic reports all publishers as having a qos depth of 0

Additional information

[fujitatomoya]

technically, with rmw_fastrtps history depth is unknown, we can see this using ros2 topic info -v. rmw_fastrtps does not store the history depth from discovery information, that leads to unknown (zero). (rmw_cyclonedds can get the actual history depth, but rmw_connextdds, which tries to store the data but it is unknown.)

see details ros2/rclpy#849

to address this issue, we need Fast-DDS to get the history depth information via discovery process to store the graph.

[MichaelOrlov]

@MiguelCompany Is it possible to make a fix for this long-lasting issue?
i.e. Populate history kind and depth during discovery.
It would mitigate many pain points related to the QoS settings for end users.

cc: @mjcarroll

[MiguelCompany]

@MichaelOrlov Yes, this is in the roadmap. The necessary ABI breaks landed in Fast DDS 3.2.0 here, but changes in the serialization of discovery messages are still pending.

After those changes, we will update rmw_fastrtps accordingly. This update would be backportable to kilted.

[MichaelOrlov]

@MiguelCompany Thank you for the update here!