Failed to find a free participant index: No free DDS participant slot

The DDS implementation could not allocate a participant because the port range for the domain is fully used.

Start free ROS 2 (DDS) → canonical

Diagnosis

When you hit this

More than the per-domain participant limit on one host, commonly hit at 120 nodes.
Zombie processes holding participants after an unclean shutdown.
Many single-node processes rather than composed nodes in one container.

Resolution

How to fix it

Clean up zombie processes
Orphaned nodes hold their participant. Check for leftover processes before assuming you hit a real limit.
Compose nodes into one process
Component containers share a participant, which is the intended fix for node-heavy systems.
Use a different domain id
Splitting across domains raises the ceiling, at the cost of cross-domain visibility.

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.