noticed: Handle deserialization error for deliver_by email when record destroyed

Probably would be nice to have an explanation in the readme like this:

class NotificationMailer < ApplicationMailer
  rescue_from(ActiveJob::DeserializationError) do |e|
    Rails.logger.info("Skipping notification due to #{e.message}")
  end

  def some_notification
    # ... params[:some_record] that can be destroyed, will raise ActiveJob::DeserializationError, so we catch it.
  end

About this issue

Original URL
State: closed
Created 4 years ago
Comments: 15 (9 by maintainers)

Most upvoted comments

PR opened! #189

joemasilotti on Jan 4, 2022

Good to know, thanks @tbcooney! I’ll open a PR with a new section to the README.

joemasilotti on Jan 4, 2022

I was just bit by this on my app and had a bunch of email notifications silently failing. Is this “common knowledge” for the gem, or job enqueuing in general? If not, I’d love to add some documentation so this doesn’t happen to anyone else.

Add it as a best practise!

The Rails guides explain that after_commit is the only callback that is triggered once the database transaction is committed. I have a propensity to not read and these errors are frustrating to track down. But, it’s well documented online that without an after_commit callback, you may see strange errors in Sidekiq to the tune of Cannot find ActionText::Attachment with ID=12345.

I’ve found this to be a best practise when using Rails callbacks (just to be clear, the best practise being the preference of after_commit to after_create).

tbcooney on Jan 4, 2022

@tbcooney: Can you share how you are enqueuing the notifications currently?

We enqueued the notifications via a callback on the model.

For example,

class Note < ApplicationRecord
  has_rich_text :content
  after_create :notify_mentioned_members
end

We probably should’ve been using after_create_commit rather than a after_create callback to ensure that transaction for both the Note and the ActionText::RichText were completed.

tbcooney on Oct 9, 2021