Update the SMTP error when request succes in the retry

Technical assistance
1
  • Used Zammad version: 6.5.2-1760355405.28ab46c4.bullseye
  • Used Zammad installation type: package
  • Operating system: Debian

Hello team ! :waving_hand:

Expected behavior

When temporary SMTP errors occur (like Timeout) , Zammad retries sending the request several times.

Usually, the retry succeeds, so the email is actually sent.

However, the agent still sees a yellow warning message, suggesting that the mail failed . Even though it was later successfully sent in the retry .

Actual behavior

The warning remains as if the message was never sent, even after a successful retry.

Suggestion

I dont think erase the warning is a good idea so : Keep the warning, but update it with additional info, for example:

Can't use Channel::Driver::Smtp: #<Net::ReadTimeout: Net::ReadTimeout> - Succes after 4 retry"

Let me know what did you think about this

Goo day :slight_smile: !

2

If you see the yellow warning in a ticket, Zmmad gave up retrying after 4 times. Even if the channel gets healthy, failed article sendouts stay that way.

This FR in its current form is technically a technical question in my opinion.

3

Thanks for your response @MrGeneration .

That’s strange, because I’ve seen this situation fews times (the yellow warning appeared, but the customer received the email)

Could there be a scenario where Zammad marks the article as failed even though server eventually delivered it well ?

I will double check my production logs next time this happens to have a better view of thats situation

1 Like
4

Yes. When your mail server returns an error, but secretly accepts the mail and sends it. In these scenarious the customer should receive the mail up to 4 times though.

MTA logs might be more helpful in those situations. Also keep in mind, that if the ticket has to to be sent articles, one of two might be sent and still cause the yellow bar if one of the two fails. This might be missleading.

1 Like
5

Yes, that makes sense. I think this is the most plausible explanation.
I’ll keep an eye on it and check the MTA logs next time it occurs.

I moved my post from FR to Technical assistance

Thanks

1 Like