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!

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.

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!

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.

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.

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!