Reconnection to Rosbridge does not reliably re-advertise topics

This comes from a report from a user of my extension, not sure what version they’re using but it’s fairly recent and on macOS.

My panel has a button that publishes a /bladescript/execute message. The panel is written as a React functional component like so:

function BladescriptPanel(
    { context }: { context: PanelExtensionContext }
): JSX.Element {
...
    // Set up rendering for the panel
    useLayoutEffect(() => {
        ...

        // Advertise that we publish scripts
        context.advertise?.("/bladescript/execute", "std_msgs/String");
    }, [context]);

    ...
}

Occasionally the user gets a complaint from Rosbridge when pressing the button that it was not expecting the publication of the /bladescript/execute message. My theory is that this has to do with when the connection is lost and then the connection gets re-established.

Am I misusing the API here?

[achim-k]

In order for rosbridge clients to publish to ROS topics, the rosbridge server has to internally create a ROS publisher which is used to publish to the actual ROS topic. This is done when a client sends an advertise operation to the rosbridge server. Future messages sent from the rosbridge client (via the publish operation) will be published to the ROS topic using the previously created ROS publisher. Note that only a single ROS publisher is created per topic. E.g. when there are more then one rosbridge clients publishing to the same topic, the same ROS publisher is used on the server side.

After all clients that previously published to this topic disconnected (or called the unadvertise operation), the internal ROS publisher is unregistered after a certain timeout (unregister_timeout). This leads to the warning messages you mentioned above being logged, which is a consequence of https://github.com/ros/ros_comm/issues/111. So in order to mitigate this, your best option is to avoid unregistering of internal ROS publishers which can be done by setting the unregister_timeout to a high enough value.

[achim-k]

It is not a big problem, but these messages cause unnecessary changes to the ros graph so it would be good if we could avoid them.

In #4653, I parameterized the _setupPublishers method. This avoids the unnecessary websocket messages and also doesn’t require adding a debounce.