使用 Postmarkapp 在 Rails 应用程序中处理电子邮件异常的最佳方法是什么?

发布于 2024-12-07 14:59:49 字数 507 浏览 0 评论 0 原文

我使用 Postmark 来处理 Rails 3 应用程序中的所有电子邮件,使用 postmark-rails gem。

有时,用户会引入错误的电子邮件或不存在的电子邮件,最终导致硬退回。 Postmark 会引发 Postmark::InvalidMessageError 错误来处理此问题,我的用户会收到非描述性 500 错误。

我想将这些错误处理到我的响应式界面中,我想知道什么是最好的策略。我现在已经有几个邮件程序了,其中有几十个,所以我不想向所有这些方法添加 begin-raise 块。将这个开始引发添加到控制器似乎也不是最优雅的解决方案。

我一直在阅读有关将 rescue_from 块添加到我的 ApplicationController 的内容,但是我不知道如何在界面中处理这个问题(也许通过调用使用errors 方法?)

我想在安装管道之前听听您的想法。

有什么想法吗?

I am using Postmark to handle all email in my Rails 3 app, using postmark-rails gem.

Now and then an user introduces a wrong email or a non-existing one with ends up giving hardbounces. Postmark raises Postmark::InvalidMessageError errors to handle this issue, that my users receive as a non-descriptive 500 error.

I'd like to handle those errors into my responsive interface and I was wondering what would be the best strategy. I have now a few mailers already with several dozens amongst all, so I don't want to add begin-raise blocks to all those methods. Adding this begin-raise to controllers also doesn't seem the most elegant solution.

I've been reading about adding a rescue_from block to my ApplicationController, but then I don't know how to handle this in the interface (maybe by calling a method that uses errors method?)

I'd like to listen to your thoughts before plumbering.

Any ideas?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

忆依然 2024-12-14 14:59:49

我们必须在 Beanstalk 中处理同样的问题。首先,我们在生产中关闭了“raise_delivery_errors”,然后我们为 ActionMailer::Base 实现了一个覆盖方法,该方法允许我们针对特定的投递动态更改该设置。像这样:

AccountMailer.raise_errors do
  AccountMailer.deliver_welcome_email(@account)
end

这使我们能够准确控制何时出现交付异常,并避免在此类错误破坏不应破坏的内容时出现问题。通常,您只想在一两个地方放置该覆盖。在我们的例子中,它是“忘记密码”和“邀请用户”功能,此时让用户知道其密码重置电子邮件/邀请未送达至关重要。在后台运行的作业中出现交付异常对任何人都没有帮助。

完成此操作后,我们向 ApplicationController 添加了一个rescue_from,它将设置 flash[:alert] 并重定向回来。

def postmark_delivery_error(exception)
  if address = derive_email_from_postmark_exception(exception)
    link = %Q[<a href="#{ reactivate_email_bounce_path(address)  }">reactivating</a>]
    msg = "We could not deliver a recent message to “#{ address }”. The email was disabled due to a hard bounce or a spam complaint. You can try #{ link } it and try again."
  else
    msg = "We could not deliver a recent message. The email was disabled due to a hard bounce or a spam complaint. Please contact support."
  end
  flash[:alert] = msg
  redirect_to :back
end

reactivate_email_bounce_path 链接到使用 Postmark API 重新激活退回邮件的控制器。您可以在这里找到更多详细信息:

http://developer.postmarkapp.com/developer-bounces因此

,在您完成所有这些之后,您的最终用户可以在处理交付错误时获得非常好的体验,而这在网络应用程序中通常不会得到解决。在 Beanstalk 中看起来像这样:

Beanstalk 反应性反弹

用户不仅可以看到他的电子邮件被退回,还可以做出反应它自己:

希望这会有所帮助。

伊利亚·萨巴宁
http://twitter.com/isabanin

We had to deal with the same problem in Beanstalk. First of all we turned off "raise_delivery_errors" in production then we implemented an override method for ActionMailer::Base that allowed us to change that setting on the fly for specific deliveries. Like this:

AccountMailer.raise_errors do
  AccountMailer.deliver_welcome_email(@account)
end

That allowed us to control when exactly we want delivery exceptions appearing and avoid problems when such errors were breaking something they shouldn't. Usually there are only one or two places where you'd want to put that override. In our case it's Forget Password and Invite User functions, when it's crucial to let users know that their password reset email/invitation wasn't delivered. Having a delivery exceptions somewhere inside a background-running job doesn't help anyone.

After we had that in place we added a rescue_from to our ApplicationController that would set flash[:alert] and redirect back.

def postmark_delivery_error(exception)
  if address = derive_email_from_postmark_exception(exception)
    link = %Q[<a href="#{ reactivate_email_bounce_path(address)  }">reactivating</a>]
    msg = "We could not deliver a recent message to “#{ address }”. The email was disabled due to a hard bounce or a spam complaint. You can try #{ link } it and try again."
  else
    msg = "We could not deliver a recent message. The email was disabled due to a hard bounce or a spam complaint. Please contact support."
  end
  flash[:alert] = msg
  redirect_to :back
end

reactivate_email_bounce_path links to a controller that uses Postmark API to reactivate bounces. You can find more details about it here:

http://developer.postmarkapp.com/developer-bounces.html

So after you have all that in place your end user can have a pretty nice experience dealing with delivery errors, something that's not usually addressed in web apps. It looks like this in Beanstalk:

Beanstalk reactive bounce

And not only a user can see that his email bounced, he can also reactive it himself:

Beanstalk reactivate bounce

Hope this helps.

Ilya Sabanin
http://twitter.com/isabanin

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文