Pending messages can be logged more than once, they shoudln't. When the logger starts up, it currently retrieves all the pending messages. If it restarts before any of the message already logged are ACK., at boot time it will re-retrieve and re-log any of the message still present in the queue.
A way to avoid it is: State 1: remember the ids for the messages in the pending queue at startup (set of messages A), with some sort of persistence among restarts (call P the stored set). State 2: TPL restarts. P contains A. State 3: at start up TPL will retrieve the current messages in the queue (set of messages B) and trigger the logging mechanism just for those messages in B but not in A. Then update P with the contents on B (aka "goto state 1"). The process is not particularly expensive and will be executed only once during the process lifetime: at startup time. A further level of checking for duplicates would imply adding at state 3 some sort of TplLogEntry matching with the already stored messages and the ones in B. This might be avoided depending of the way the Channel Dispatcher handles msg-id for pending messages after each system reboots (aka when TP is completely restarted).
> State 1: remember the ids for the messages in the pending queue at startup (set > of messages A), with some sort of persistence among restarts (call P the stored > set). Note, message tokens will likely to be more reliable than pending message ids.
*** This bug has been marked as a duplicate of bug 26868 ***
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.