Strategy to gracefully handle restarts of master and/or other nodes

[merlinran]

It may be okay for many applications to just restart everything, but if goroslib is used to interact with ROS based system, it's possible that other nodes, or even master, get restarted at any time. Here's an example in my case - the publisher it used to connect no longer exists so it keeps retrying.

2022-12-20T23:09:44.916-0500	DEBUG	ros/ros.go:349	subscriber '/trexo_status' is connecting to publisher 'odroid:38725'
2022-12-20T23:09:44.919-0500	ERROR	ros/ros.go:355	subscriber '/trexo_status' got an error: Post "http://odroid:38725/RPC2": dial tcp 192.168.18.1:38725: connect: connection refused

For subscriber, one way I'm thinking is to close the subscriber if it encounters non-temporary errors (Edit: Temporary() is depreciated), then adds a Closed() method to many things so the caller can detect it and re-create the node, for example, but my knowledge on ROS is very limited so this may not work out. Any idea will be much appreciated.

[merlinran]

Saw this conversation #87 (reply in thread) right after posting this. For services the caller would notice peer shutdown if call periodically, but subscriber doesn't expose the error to the caller. Does it mean we have to use fixed ports for publishers?

[merlinran]

Oh well how dumb I am. Can simply restart the node if not received from the subscriber for X seconds.