palkan / abstract_notifier

ActionMailer-like interface for any type of notifications

Hey / Привет 👋

My name is Vladimir (or Вова), and I'm a principal backend engineer at @evilmartians.

📕 My book "Layered design for Ruby on Rails applications" is avalable now: Amazon | Packt

I'm working on:

• Making real-time apps rock with @anycable (built with Ruby and Go).
• Bringing edge Ruby features to all Rubies with @ruby-next—a transpiler for Ruby.
• Helping Ruby devs to write faster tests with test-prof.
• ...and other projects, such as: Action Policy, Logidze, Anyway Config and many more.

Check out some of my blog posts:

• The future of full-stack Rails
• Real-time stress: AnyCable, k6, WebSockets, and Yabeda
• Ruby on Whales: Dockerizing Ruby and Rails development
• System of a test: Proper browser testing in Ruby on Rails
• Anyway Config: Keep your Ruby configuration sane
• RuboCoping with legacy: Bring your Ruby code up to Standard

...and conference talks:

• Rails on Wasm
• Rails as a piece of birthday cake
• The pitfalls of real-time-ification (RailsConf 2022)
• Weaving and seaming mocks (RubyConf 2022)
• Frontendless Rails Frontend (RailsConf 2021)
• Between monoliths and microservices (RailsConf 2020, component-based architecture using Rails Engines)
• Ruby Next: Make old Rubies quack like a new one (RubyConf 2019)
• Terraforming legacy Rails applications (RailsConf 2019)
• High-speed cables for Ruby (RubyConf 2018)
• 99 problems of slow tests (Paris.rb 2018)

abstract_notifier's Issues

Wrap around notification call similar to the around_action

Is your feature request related to a problem? Please describe.

For the sake of easiness and reduce verbosity in mailers it's possible to set locale of current user like:

  before_action do
    if params
      @user = params[:user]
    end
  end

  around_action do
    I18n.with_locale(@user.locale, &block)
  end

I found there are no around wrappers in abstract notifier code.

Describe the solution you'd like

Would be nice to have similar ability to wrap some code around notification call, similar to the actionmailer.

Describe alternatives you've considered

Currently it's only possible to wrap public_send which calls notifications like so:

  def initialize(notification_name, user:, **params)
    @user = user
    super
  end

  def public_send(*)
    I18n.with_locale(@user.locale) do
      super
    end
  end

Additional context

Lets discuss and I'm able to provide a solution.

Option to disable default `notifier` line with ActiveDelivery?

Would you be open to having an option (somewhere, not sure where) that would disable creating the default notifier line for ActiveDelivery? Looking at these lines here:

    # Only automatically register line when we can resolve the class
    # easily.
    if "".respond_to?(:safe_constantize)
      ActiveDelivery::Base.register_line :notifier, Notifier, resolver: Notifier::DEFAULT_RESOLVER
    end

I'm using name other than notifier and it would be nice to be able to disable the default so I don't have an extra line registering that I don't need. Happy to do a pull request if you have insight on how you wan options handled. Thanks for releasing these gems!

Ruby 2.7/3.0 support

Is your feature request related to a problem? Please describe.

When using this gem on projects with ruby 2.7 , there a few deprecation warnings that will break on ruby 3.0 (related to how ruby 3.0 handles keyword arguments).

Describe the solution you'd like

Release a major version that drops support for ruby <= 2.6 (because this version already hit EOL) that fixes those warnings

Describe alternatives you've considered

I've considered forking the project and fixing the deprecation warnings locally

Additional context

I am currently working on fix those warnings. I hope to open a PR soon. Let me know if there's something else I can do here.

have_enqueued_notification fails when 2 notifications with same message are enqueued

When testing a method that calls 2 different notification methods which sends exactly same message, the expect with have_enqueued_notification fails, saying that it wasn't enqueued not even once:

expected to enqueue notification: {:body=>"Here we go again"} exactly once, but haven't enqueued anything

I didn't test similar cases, like enqueue twice w/ same method, but at least the problem exists for this specific case.

RSpec matchers doesn't work

I have the same issue with testing like described here:

You must pass an argument rather than a block to use the provided matcher (have not delivered to MyDelivery), or the matcher must implement `supports_block_expectations?

when spring is running.

So adding require "abstract_notifier/testing/rspec" makes a trick! Let's add notice to the docs:

---

NOTE: test mode activated automatically if RAILS_ENV or RACK_ENV env variable is equal to "test". Otherwise add require "abstract_notifier/testing/rspec" to your spec_helper.rb / rails_helper.rb manually. This is also required if you're using Spring in test environment (e.g. with help of spring-commands-rspec).

---

Let me know if I could send PR or you will do it on yours end.

Thanks, for the great gem and all your open source works!

An error raised in an ActiveDelivery line behaves differently than one raised in an ActiveMailer line

Am using ActiveDelivery in combination with AbstractNotifier. Thanks so much for both contributions. I have a few custom abstract notifier lines setup as well as a mailer line (default). Great results!

I have a question/issue with error handling and job queueing.

What I am observing is that when an error is raised inside the AbstractNotifier it halts the execution of all the other delivery lines during the process of the delivery (even when using #notify to enqueue the jobs). Whereas if an error is raised inside of an ActiveMailer line the error does not stop the delivery lines from being enqueued (and instead the error actually gets raised when the enqueued job runs).

Simple example:

class FooBarDelivery < ApplicationDelivery; end

class FooBarNotifier < AbstractNotifier::Base
  def foo
    raise "This will halt the operating of `FooBarDelivery.notify(:foo)`"
  end
end

class FooBarMailer < ApplicationMailer
  def foo
    raise "This will *not* halt the operation of `FooBarDelviery.notify(foo)`"
  end
end

# => FooBarDelivery.with(foo: :bar).notify(:foo)

So the raised error in the abstract notifier halts everything; the raised error in ApplicationMailer does not. This is tripping me up in particular with nested job queues because I had one abstract notifier line that would error but all the other lines were being retried resulting in a lot of "spam" (as the one line never was getting delivered).

I would have expected them all to behave like ActiveMailer — they aren't actually executed until after the job is queued.

I wonder if I have my driver setup wrong or is this just how it happens to be?

Thanks!