well injecting without the config section should_enqueue_log_record, seems to work..
for now
customer is done sending.. so I cannot inject more email atm.
I will try to see if I can do a stress test myself…
ok, that error message should be harmless; we should pick one of the ipv4 addresses later in the connection plan. You should be able to verify that from the delivery logs.
if saw that I can discard emails in the lua
so then I can create a mail storm in a controlled way…
these hangup kind of issues are the worst to debug
I have seen mails being send so that worked now … and when not injecting mail it empies the mail queue
so the working theory is that this is related to the webhook?
or at least it will try
I think so …
so I could disable it… if the hangup happens again
I was unsure if disabling would confuse kumo with the webhook\2 queue
if it still had stuff in there
well, I’d like to get to the bottom of that hang, because it is not expected behavior
yes me too
I do have a dev setup of the production and should be able to reproduce
but need to find some time for that
hmm I figure that I can make something like this work with an if statement on an domain or email address:
kumo.on('smtp_server_message_received', function(msg)
-- Accept and discard all messages
msg:set_meta('queue', 'null')
end)
And with that at least I would inject lotsa mails.. but will that then also test the webhook for delivery