How should we handle multiple publishers simultaneously posting requests?

If multiple unrelated publishers are posting different goals to ~/destination/goal at the same time, then there is ambiguity about what goal the robot is actually meant to pursue.

It is important to consider that different subscribers may receive messages in a different order if the messages are coming from different publishers. Therefore if we naively accept the "latest" (most recently received) request as the "true" request then different subscribers could fall out of sync with each other.

If we put a timestamp inside the message definitions and judge the "latest" message on the most recent timestamp then there are a few issues:

• Different system clocks may fall out of sync (I've seen hours and up to a day of sync issues), creating substantial bias in which message is most "recent"
• Publishers could spoof their timestamp or forget to fill it in
• Timestamps could result in a draw, although the probability of this is extremely low when clocks have nanosecond precision

Note that some RMW implementations provide source timestamps in the message metadata, but this is not guaranteed to be provided and shares some of the same potential issues as an internal timestamp, especially the first problem of system times falling out of sync.

I would recommend that we make it a system-level requirement that each ~/destination/goal topic should only have one publisher publishing to it.

• Different instances of the topic may have different publishers, e.g. security_bot_1/destination/goal could have a different publisher than cleaning_bot_3/destination/goal
• The same publisher can publish to multiple different topic instances, e.g. security_bot_schedule can publish to security_bot_1/destination/goal, security_bot_2/destination/goal, etc...

However I am open to other ideas on how to settle this, for example queuing up incoming requests or putting a string requester_id in the message definition and having a priority scheme to choose between the publishers.

Start by reviewing the ~/destination/goal topic and the relevant message definitions, then compare the proposed single-publisher requirement with queuing and requester_id alternatives. Done means agreeing on one system-level policy that prevents subscribers from acting on conflicting goals.