Log Oban errors (and still report them to Sentry)

[ruslandoga]

This PR adds logging for Oban errors. The reasoning is that most self-hosters don't have Sentry configured which makes these errors invisible.

Here's how it'd look after this PR:

[macobo]

It's worth adding something to changelog as well!

[aerosol]

IMHO it's ok not to do the CE branching. It doesn't hurt to log regardless of the build.

[ruslandoga]

I thoughts so too, but decided to go with CE-only since otherwise EE would receive duplicate Sentry reports since error logs get sent there too:

analytics/config/runtime.exs

Lines 33 to 35 in e7332d9

	config :logger, Sentry.LoggerBackend,
	capture_log_messages: true,
	level: :error

[aerosol]

Just replace Sentry.capture_exception that's beneath with Logger.error then?

[ruslandoga]

The reports would be a bit different (#3336), is that OK? I'll get some screenshot for the differences for these particular errors.

[ruslandoga]

Sentry.capture_exception screenshot

Logger.error screenshot

The differences I see are:

• Sentry.capture_message groups / fingerprints by stacktrace instead of error message (this info is at the very bottom of the page)
• using Sentry.capture_message renders stacktrace in a nice table :)

Also, to make it work, I needed to modify the Logger call to

Logger.error(
  Exception.format(:error, meta.reason, meta.stacktrace),
  sentry: %{extra: extra}
)

which removes the "Background job failed" message and makes the actual log appear like this

16:52:52.129 [error] ** (ArgumentError) The email address `plausible@localhost` is invalid.

    (mail 0.3.1) lib/mail/renderers/rfc_2822.ex:134: Mail.Renderers.RFC2822.validate_address/1
    (mail 0.3.1) lib/mail/renderers/rfc_2822.ex:141: Mail.Renderers.RFC2822.render_address/1
    (mail 0.3.1) lib/mail/renderers/rfc_2822.ex:97: Mail.Renderers.RFC2822.render_header/2
    (elixir 1.17.1) lib/enum.ex:1703: Enum."-map/2-lists^map/1-1-"/2
    (elixir 1.17.1) lib/enum.ex:1703: Enum."-map/2-lists^map/1-1-"/2
    (mail 0.3.1) lib/mail/renderers/rfc_2822.ex:174: Mail.Renderers.RFC2822.render_headers/2
    (mail 0.3.1) lib/mail/renderers/rfc_2822.ex:56: Mail.Renderers.RFC2822.render_part/2
    (bamboo_mua 0.2.2) lib/bamboo_mua.ex:57: Bamboo.Mua.deliver/2
    (bamboo 2.3.0) lib/bamboo/mailer.ex:208: Bamboo.Mailer.deliver_now/4
    (bamboo 2.3.0) lib/bamboo/mailer.ex:231: Bamboo.Mailer.deliver_now!/4
    (plausible 0.0.1) lib/workers/notify_exported_analytics.ex:36: Plausible.Workers.NotifyExportedAnalytics.perform/1
    (oban 2.17.2) lib/oban/queue/executor.ex:129: Oban.Queue.Executor.perform/1
    (oban 2.17.2) lib/oban/queue/executor.ex:74: Oban.Queue.Executor.call/1
    (elixir 1.17.1) lib/task/supervised.ex:101: Task.Supervised.invoke_mfa/2
    (elixir 1.17.1) lib/task/supervised.ex:36: Task.Supervised.reply/4

which is probably less intuitive for self-hosters.

[ruslandoga]

Seems like I can make both look the same by passing crash_reason: {meta.reason, meta.stacktrace} to Logger. Then I would also be able to modify the message to be more user-friendly since it won't be used in Sentry.

[ruslandoga]

I've updated the PR and now it logs a "self-hoster-friendly" message but reports a more structured Sentry event, the same way as before.