Incompatible QoS — Publisher and subscriber QoS do not match

Both endpoints exist and discovered each other, but their QoS policies are incompatible, so DDS refuses to connect them. The topic looks alive and no data flows.

Start free ROS 2 (DDS) → canonical

Diagnosis

When you hit this

A BEST_EFFORT publisher and a RELIABLE subscriber. The subscriber demands more than the publisher offers, so no match.
VOLATILE durability against a TRANSIENT_LOCAL subscriber expecting late-joiner data.
Mismatched DEADLINE or LIVELINESS, common when mixing sensor-data profiles with defaults.

Resolution

How to fix it

Remember the offered/requested rule
The publisher's offered QoS must be at least as strong as the subscriber's requested QoS. RELIABLE publisher to BEST_EFFORT subscriber works; the reverse does not.
Inspect both ends
ros2 topic info --verbose prints the QoS on each endpoint. The mismatch is visible immediately.
Watch the sensor-data profile
rclcpp::SensorDataQoS is BEST_EFFORT. Subscribing with default RELIABLE QoS silently fails to connect.

Normalization

What Forge does about it

This is a configuration or addressing mistake on the wire, upstream of anything Forge sees. Where Forge helps is the step after you fix it: once the point returns data, its vendor tag name maps to a canonical field automatically, so you do not also have to hand-maintain a name table for every point you just re-addressed.