ROS 2 QoS Compatibility for Transient Local Durability

Answer

A publisher using TRANSIENT_LOCAL durability does not guarantee delivery of the last N samples to a subscriber whose reliability is set to BEST_EFFORT. Durability only ensures that the publisher stores recent samples for late‑joining subscribers; whether those stored samples are actually delivered depends on the reliability policy. With BEST_EFFORT the middleware may drop samples if the subscriber is not ready, so the history depth is not honored as a delivery guarantee.

Confirmed facts

• Durability matching follows the order VOLATILE < TRANSIENT_LOCAL < TRANSIENT < PERSISTENT. A publisher can match a subscriber only if its offered durability is ≥ the subscriber’s requested durability.
• A publisher offering TRANSIENT_LOCAL matches subscribers that request either VOLATILE or TRANSIENT_LOCAL durability. It does not match TRANSIENT or PERSISTENT subscribers.
• History (keep_last/depth) does not influence durability matching; it only controls how many samples are stored when the durability policy requires storage.

Likely explanation

When reliability is BEST_EFFORT, the DDS middleware makes a best‑effort attempt to deliver each sample but does not retry or recover lost samples. Even if the publisher has stored the last N samples because of TRANSIENT_LOCAL durability, a BEST_EFFORT subscriber may miss them if it is not ready at the moment the publisher attempts to send. Therefore, the durability guarantee is overridden by the reliability mismatch: no guaranteed delivery of the history.

Steps to verify or fix

1. Check the current QoS on the topic: ros2 topic info <topic_name>. Look for the Offered QoS (publisher) and Requested QoS (subscriber) fields, especially durability and reliability.
2. If you need guaranteed delivery of the last N samples to late‑joining nodes, change the subscriber’s reliability to RELIABLE (via XML profile or code). Keep the publisher’s durability as TRANSIENT_LOCAL and ensure its history depth is at least 1 (keep_last: {depth: 1} or higher).
3. After changing reliability, repeat ros2 topic info to confirm that both sides now show RELIABLE reliability and compatible durability.
4. Optional test: start the publisher with TRANSIENT_LOCAL and depth >0, then start the subscriber after a few publications; the subscriber should receive the most recent sample(s) only when its reliability is RELIABLE.

Missing diagnostic detail

To confirm whether any samples are stored at all, please specify the Keep Last history depth configured on the publisher (or subscriber) for this topic. If the depth is 0, no samples are retained regardless of durability, which would explain missing data even with a reliable subscriber.