An alternate solution to previous suggestion in this bug could involve diagnostic pipelets in the queue runners. Maybe the queue runner processing the outgoing emails can signal a problem if the message's incoming timestamp is older than our service level we set for the time to complete the outgoing mail. A separate pipelet could be in the archive queue to manage a different service level. A piplet can add metadata to a message might be able to add diagnostic data to messages when they enter queues, rather than looking at existing message data, or a log.
https:/ /wiki.canonical .com/IncidentRe ports/2011- 11-11-LP- DelayMailingLis tsSendingMail
documents slow delivery that might have been caught is we had end-to-end monitoring. Only large lists were affected by slow delivery, so effective monitoring may need to use a large list to provide the state.
An alternate solution to previous suggestion in this bug could involve diagnostic pipelets in the queue runners. Maybe the queue runner processing the outgoing emails can signal a problem if the message's incoming timestamp is older than our service level we set for the time to complete the outgoing mail. A separate pipelet could be in the archive queue to manage a different service level. A piplet can add metadata to a message might be able to add diagnostic data to messages when they enter queues, rather than looking at existing message data, or a log.