I’m running Kumo version 2024.09.02.062344.c5476b89 and I observed an odd behavior.
Due to an error in queue management lua code - queue config could not be created (threw a lua error).
What is odd is that the feeder got temp rejection (421 4.3.0 technical difficulties while the message actually hit the spool. Problem is - the application will obviously retry on a temp error, leading to multiple copies of the same email being spooled and (when lua error fixed) - sent. Thankfully this happened in dev/test environment.
Any advice on how to handle this since from what I understand technical difficulties is generic response and there is not much to differentiate from application side
Any advice here? I was just about to push kumo into service. If it’s only the get_queue_config that’s affected - can test the code up-the-wazoo and say all good since it’s basically “select egress pool with default”, other queue configs are static
the issue is that the QueueManager::insert doesn’t try to roll back and remove messages from the spool if the queue config and/or egress path config hooks propagate an error
You can use kumod --validate to verify your configs (especially the helpers) before you push them into production, but if you are doing custom lua for your hooks, you will need to find a way to satisfy yourself that the configs are good
Since on the other end of the feeder interface is a queue-backed email forming app, would running with deferred_spool mitigate this since forming app will retry if it does not get a 2xx back?
We’ll test our lua code as much as possible, but is the get_queue_config hook only one affected or is there anything more that needs the deepest depths of scrutiny while this issue is addressed?