No publishers discovered — Topic exists but nothing is discovered

The subscriber never sees the publisher at all. This is a discovery failure below the ROS layer, not a QoS mismatch.

Start free ROS 2 (DDS) → canonical

Diagnosis

When you hit this

Different ROS_DOMAIN_ID values. Nodes in different domains are invisible to each other by design.
Multicast blocked between hosts, which most DDS implementations need for discovery.
Different RMW implementations on each side, or incompatible versions of the same one.
Docker containers on separate bridge networks without host networking.

Resolution

How to fix it

Check ROS_DOMAIN_ID on both sides
It must match exactly. An unset variable defaults to 0, so one side exporting it and the other not is a silent split.
Verify multicast
Discovery relies on multicast by default. Many enterprise networks and Docker bridges drop it; configure a discovery server or unicast peers instead.
Match RMW implementations
Confirm RMW_IMPLEMENTATION is the same on both. Cross-vendor DDS interoperability is not something to rely on in production.

Normalization

What Forge does about it

This is a transport failure, so there is nothing for Forge to normalize: the reading never arrives. What Forge does is refuse to let the gap look like good data. The read-time dropout check flags a field that fell to zero and recovered as a communication glitch rather than a real measurement, and the stuck-sensor check fires when a value repeats for 20 consecutive readings — which is what a cached or last-known value looks like after a link drops. Forge does not retry or reconnect for you; that is your client's or your gateway's job.