[18257] Version compatibility issue for participant discovery when upgrading to version 2.10.1

[vfrcode]

Is there an already existing issue for this?

• I have searched the existing issues

Expected behavior

An application that has implemented the on_participant_discovery callback (having 2 parameters) and was compiled against the fastrtps library v2.10.0 was expected to still be able to discover new participants after upgrading the installed runtime library to v2.10.1.

Current behavior

The on_participant_discovery callback is never called when the runtime library is of version v2.10.1.

This is because the empty implementation of the on_participant_discovery callback function of DomainParticipantListener is inside the header file and is virtual, and therefore the compiled application has the empty implementation compiled into it. Version v2.10.1, however, relies on the new default implementation of the on_participant_discovery callback function with 3 parameters to relay the call to the on_participant_discovery with 2 parameters, but this new default implementation is not used by the application.

Hence, no application that uses this callback and was compiled with versions prior to v2.10.1 will be able to work properly when the runtime library is upgraded to v2.10.1.

Steps to reproduce

1. Implement an application that implements the on_participant_discovery callback function that has 2 parameters.
2. Build with v2.10.0
3. Run the application with runtime library libfastrtps version v2.10.1
4. Note that the callback is never called.

Fast DDS version/commit

The bug is introduced in commit 924593a (DomainParticipant::ignore_participant implementation (#3412).

Platform/Architecture

Ubuntu Focal 20.04 amd64

Transport layer

Default configuration, UDPv4 & SHM

Additional context

No response

XML configuration file

No response

Relevant log output

No response

Network traffic capture

No response

[JesusPoderoso]

Hello @vfrcode , thank you for the report.
The documentation would be updated to report this issue, and all empty implementations would be moved from the headers to the source files to prevent this problem from occurring in following releases.
Good catch!

[vfrcode]

Hi Jesus,

A work-around for now would be to just call both callback functions instead of relying on the implementation of the one to relay the call to the other. I'm not sure whether the user of the library expects both callback function to be called, or only one of them. I did not see the header file describing the behavior, and thus, from my point of view, I would expect both callback functions to be called anyway if I'd have overridden them both.

This would make sure that existing application keep working after upgrading the runtime libaries to the newest version. Would this be an option ?

[MiguelCompany]

@vfrcode

A work-around for now would be to just call both callback functions...

In fact, I think this would be the only ABI-compatible way of tackling this. I went ahead and implemented this approach in #3479