Breaking changes coming to Bamboo v2.0.0

[germsvel]

👋 Hi,

Thanks for maintaining this Bamboo adapter. 🥳

There will be a breaking change coming to Bamboo in v2.0.0 where the deliver_now function will no longer raise an error on failure to deliver an email. Instead, it will return :ok or :error tuples. That way, users of the library can decide how to handle the errors. I've completed that work in beam-community/bamboo#571.

I've also added a deliver_now! function that is meant to behave exactly as deliver_now currently behaves. So, there's an easy upgrade path for users who don't want to handle their own errors. They can change deliver_now -> deliver_now!.

(There are also deliver_later corresponding changes, but from the adapter's perspective, I don't know that it matters).

What that means for adapters

In order for people to upgrade to Bamboo v2.0.0, the adapters will need to stop raising errors when they fail to deliver emails. In order to accommodate that, the adapter's callbacks are changing like this:

- @callback deliver(%Bamboo.Email{}, %{}) :: any
+ @callback deliver(%Bamboo.Email{}, %{}) :: {:ok, any} | {:error, Exception.t() | String.t()}

In other words, adapters should now return an {:ok, response} tuple or an {:error, error} tuple, where the error is either an exception struct that can later be raised or an error message.

To facilitate that work, PR 571 also introduces a Bamboo.ApiError.build_api_error function that can be used by adapters — if you want to easily build an error to return in the {:error, error} response.

Sample changes to other adapters

I have already done some changes to the Sendgrid, Mailgun, and Mandrill adapters. They might serve as a guide:

• Sendgrid changes: Update SendGrid Adapter to return ok/error tuple beam-community/bamboo#572
• Mailgun changes: Update Mailgun.deliver to return ok/error tuples beam-community/bamboo#573
• Mandrill changes: Update Mandrill to return ok/error tuples beam-community/bamboo#574

Why open this issue?

I wanted to open this issue for two reasons:

1. To let you know about the changes that are coming up (all of the above), and
2. To ask you if there's anything I can do to help with the transition.

Unfortunately, I can't offer to open PRs to make the changes in all the adapter repos, but if it's helpful, I'd be happy to review PRs.

And if there's some change to Bamboo that would make it easier to work with your adapter, or if you have suggestions or comments on PR 571, I'd love to know.

Thanks again for maintaining this adapter, and please feel free to close this issue whenever you've read it (if it's of no further use). It just seemed like the easiest way to communicate about the upcoming changes with you.

[Aduril]

As far as I see the the major change is towards the API of Bamboo.Mailer (please do not trust my word, check for yourself).

So the change should be an easy version upgrade, right?

[jarvisjohnson]

I think @Aduril is right, bumping the bamboo version seems to be all that is needed.

Have created a PR for this - #177

[germsvel]

Hi @Aduril and @jarvisjohnson, thanks so much for being quick to look through this. You're right that the main changes in Bamboo 2.0 are to the Bamboo.Mailer API. But in order for that change to work — for bamboo and bamboo_smtp users to be able to handle errors when emails fail to deliver — we also need to change what the adapter's deliver/2 function returns (See the changes to the adapter deliver callback):

-  @callback deliver(%Bamboo.Email{}, %{}) :: any
+  @type error :: Exception.t() | String.t()

+  @callback deliver(%Bamboo.Email{}, %{}) :: {:ok, any} | {:error, error}

That means adapters should no longer raise errors in the adapter code when failing to deliver emails. Instead they should return an {:error, error} tuple, so that Bamboo can handle that. Looking at the smtp_adapter.ex file, my guess is that these are the lines that should now return an error instead of raising one:

bamboo_smtp/lib/bamboo/adapters/smtp_adapter.ex

Lines 98 to 108 in 2c2643e

	defp handle_response({:error, :no_credentials = reason}) do
	raise SMTPError, {reason, "Username and password were not provided for authentication."}
	end
	defp handle_response({:error, reason, detail}) do
	raise SMTPError, {reason, detail}
	end
	defp handle_response({:error, detail}) do
	raise SMTPError, {:not_specified, detail}
	end

If instead of raise SMTPError, bamboo_smtp returns {:error, %SMTPError{}}, then users who call Mailer.deliver_now will get that error tuple back. The users can then handle that in whatever way they see fit (e.g. retrying to send, or keeping a log of what failed, etc.)

For users who call Mailer.deliver_now!, Bamboo will raise the error the adapter passes back, so it'll do an raise %SMTPError{}.

As for the successful case, it seems that bamboo_smtp already returns an {:ok, response}, so that's perfect.

Does all that make sense?

[jarvisjohnson]

Totally, thanks - I'll make some updates for it to return an :error tuple

[MatheusBueno782]

Since the pull request #177 that address to this issue was merged I am closing it.

thanks all for the contribution 🙂.