Minimum version required for each release of DDS Record & Replay

[dohunnim]

Hi,

I'm currently using FastDDS Monitor to monitor subscribers and publishers, and FastDDS Record & Replay to record the traffic. I'm using FastDDS v2.7.1 and FastDDS Record & Replay v0.2.0. When I open the mcap file on Foxglove, I only see the ddsrecorder status during playback and there are errors in the "Problems" tab saying that the Schema for each of the topic that I would like to monitor to be empty. I'm wondering if it's a version incompatibility issue. Do you have minimum required version information for FastDDS for each of the Record & Replay release?

Thank you,

[juanlofer-eprosima]

Hi @dohunnim , thanks for using our products.

First of all, note that DDS-Record-Replay is capable of recording and replaying any kind of DDS traffic. However, for being able to visualize generated mcap files in Foxglove Studio, it is required that the publishing applications properly configure dynamic types.

If after following these steps you are still not able to visualize data, we can look into the possible version incompatibility you mention. It could also be the case that the types used by your publishing applications are currently not supported by the underlying Fast-DDS middleware.

Cheers.

[dohunnim]

Hi @juanlofer-eprosima ,

Thanks for a quick response.
I was able to convert to dynamic types, but looks like create_participant segfaults and when I backtrace, looks like it's due to my IDL definitions having a struct defined within a message (based on discussion here: eProsima/Fast-DDS#2635)
Does this mean there's no way for me to inspect a recorded mcap file for message contents?
And just to clarify your previous statement, are dynamic types required for record/replay even when I don't need to inspect message contents?

Thank you,

[juanlofer-eprosima]

Hi @dohunnim ,

Please have a look at this comment on a similar issue, and see if that would solve the segfault for your case.

Regarding your second question, no, they are not required for record&replay as long as your subscribing applications already have compiled the type support for the types being replayed. However, it could also be the case that your subscribing applications do not have these types available, and so they might make use of dynamic types to receive them and create readers on runtime (as long as this information was previously recorded and stored in the corresponding mcap file).
For more information, see related documentation sections:

• Only with types
• Record types
• Replay types

Regards