The current design for deadline and liveliness QoS settings do not support differentiating keyed instances of Topics. As a result, you are not able to determine which instance has violated the QoS policy if your subscription encompasses multiple instances. Supporting this would be useful for cases like when you have multiple robots publishing to a single topic but using a different instance identifier, such as a serial number for the robot. If one of your robots starts failing to publish data to the topic then you could get notified of the liveliness or deadline violation, but you wouldn't be able to tell which of them had caused it.
In order to support this use case, changes would be needed to the callback structure in order to include information about the key identifier for the instance that has violated the policy. This value would need to be optional based on if the message type used for the topic specifies a key or not. How this key is represented may also depend on how ROS 2 decides to represent instanced subscription for topics. It will probably require some code generated for a message in order to cast the key data to the proper type. The C++ api may be able to leverage templates to do this automatically for the user, but rclpy will need a way to do this for the C message types as well.
The current design for deadline and liveliness QoS settings do not support differentiating keyed instances of Topics. As a result, you are not able to determine which instance has violated the QoS policy if your subscription encompasses multiple instances. Supporting this would be useful for cases like when you have multiple robots publishing to a single topic but using a different instance identifier, such as a serial number for the robot. If one of your robots starts failing to publish data to the topic then you could get notified of the liveliness or deadline violation, but you wouldn't be able to tell which of them had caused it.
In order to support this use case, changes would be needed to the callback structure in order to include information about the key identifier for the instance that has violated the policy. This value would need to be optional based on if the message type used for the topic specifies a key or not. How this key is represented may also depend on how ROS 2 decides to represent instanced subscription for topics. It will probably require some code generated for a message in order to cast the key data to the proper type. The C++ api may be able to leverage templates to do this automatically for the user, but rclpy will need a way to do this for the C message types as well.