Zenoh Router fails to route Publications when one Endpoint is invalid and exit_on_failure: true is configured

[nametable]

Describe the bug

Also refer to this Discord support thread: https://discord.com/channels/914168414178779197/1287809049034887298

Zenoh router fails to deliver publications when one endpoint fails to connect and exit_on_failure: true is configured. Although the router still shows messages received in its log.

My setup is a microcontroller publishing over serial with zenoh-pico and a simple z_sub example running on the host computer. When I have an extra endpoint listed that fails to connect, I see log messages about publications from the microcontroller, but they don't make it to the subscriber. Once I remove the extra endpoint from the configuration, publications make it to the subscriber successfully.

Here is my router configuration: zenoh_config.json5.txt

My expectation would be that since the publications show up in the log, they should still make it to subscribers, or the entire zenohd should fail and stop.

To reproduce

1. Start a subscriber on the host listening for **
2. Create a configuration for zenohd with the router type and multiple endpoints in the listen section, with one being a serial connection that doesn't exist (ie serial//dev/ttyACM7#baudrate=115200 or something)
3. Run zenohd with the configuration with trace on, and the transport_serial feature enabled
4. Connect a microcontroller on a valid endpoint, and see that messages are seen by Zenohd
5. See that messages are not received on the subscriber (unless you set listen exit_on_failure: false, or remove the invalid endpoint)

System info

Host
OS: Linux
Zenoh Version: v1.0.0-beta.3

Microcontroller
OS: Zephyr
Zenoh Pico Version: release/1.0.0.9

[OlivierHecart]

The observed behavior is expected for the provided conf.

1. exit_on_failure: true so we try listeners sequentially and only return a valid session once all opened (or return error in case of failure: if unable to open in the allocated time).
2. timeout_ms: -1 so timeout is infinite, opening will never fail and continue forever until eventually opening all listeners remaining in an 'initializing' state until then.

Closing the issue.