Should we limit this republishing only for commands in their terminal state? If not, there's the risk of the even the intermediate command states like scheduled or executing getting resent, risking duplicate execution of the same logic by any external component listening on them.

Though there isn't any official contract that says these messages will only be published exactly once. But generally such listeners are not doing control (as control logic should be in the workflow itself), so triggering twice on a status change should not be a problem.

Just using qos 1 is enough to receive a duplicate message (without publishing the status change twice).

Should we limit this republishing only for commands in their terminal state?

This would introduce the same issue on intermediate states (.e.g the "executing" state being never published).

If not, there's the risk of the even the intermediate command states like scheduled or executing getting resent, risking duplicate execution of the same logic by any external component listening on them.

The agent protects itself from reacting to messages of which it is the publisher.

Other components, such as the mappers, should be prepared to receive a status twice.

Just using qos 1 is enough to receive a duplicate message (without publishing the status change twice).

It's also enough to restart, the messages being retained. If the c8y mapper stop after sending an EXECUTING 501 message and restart before the command is successful, a second EXECUTING 501 will be sent.

Just using qos 1 is enough to receive a duplicate message (without publishing the status change twice).

I have always assumed that users would send critical messages like commands only with QoS 2, as they might expect once-and-only-once execution for such things. But yeah, if the users are already expected to be resilient to duplicate delivery, esp since most cloud platforms don't support QoS 2 either, I guess this is okay.