Thanks for your input and happy new year to you!
The logs set debug level prove to be inconclusive: the runner is handing the message over to the archive runner which in turn forwards to the message to HyperKitty. HyperKitty, not checking if a message with the same ML name and msgid is already present in the DB forwards this to Postgres for storage.
The following questions remain to further the RCA:
- How to obtain additional logging information beyond the settings outlined below [1]?
- Why does the archive runner forward a message to HyperKitty if it's already done this in the past (or is this another try if the message hasn't been archived successfully - how do I check this from the archive runner's perspective if the archiver only logs the entry "HyperKitty archived message <msgid> to the HyperKitty REST URL"?
- Any additional insights you might be able to share (additional logging configuration, etc.) is greatly appreciated!
[1] mailman.cfg excerpt:
[runner.pipeline] instances: 4
[runner.out] instances: 1
[logging.smtp]
#level: debug
[loggging.database]
#level: debug
[logging.runner]
#level: debug
[logging.pipeline]
level: debug
qualname: pipeline
propagate: 0
[logging.lmtp]
level: debug
path: lmtp.log
#
[logging.archiver]
level: debug
[logging.mischief]
#level: debug
[logging.plugins]
#level: debug
mailman-web.py excerpt:
LOGGING = { 'version': 1, 'loggers': { 'hyperkitty': { 'level': 'DEBUG', 'propagate': True } } }
The GitLab issue you mentioned I raised due to my incorrect configuration of the # of runner instances was due to the assumption that I suspected a single pipeline runner might not be sufficient with the load and hence my attempt at increasing this.