Say when an emailed error was reopened, and let apps build the subject

[namolnad]

Say when an emailed error was reopened, and let apps build the subject

I know email_subject may be a niche request, and I'd understand if it's more than you want to take on. The "(reopened)" fix at the start stands on its own (see below).

With email_every_occurrence = false, Solid Errors emails an error's first occurrence and the occurrence that reopens a resolved error. Both emails get the same subject (🔥 TimeoutError), so a fix that didn't hold looks the same as a brand-new problem until you open the email. The subject is usually where you decide how urgent an email is.

What changes

By default: a reopened error's email now says so: 🔥 TimeoutError (reopened). Every other subject is unchanged.

email_subject: a new setting. Set it to a proc to build the subject yourself. The proc gets the error, the occurrence, and reason: :created or :reopened when the occurrence opened its error, nil for any other occurrence. email_subject_prefix is still added in front of what it returns.

config.solid_errors.email_subject = ->(error:, occurrence:, reason:) {
  count = error.occurrences.where(id: ..occurrence.id).count
  subject = "#{error.severity_emoji} #{error.exception_class}"

  case reason
  when :reopened then "🔄 REOPENED: #{subject}"
  when :resolved then "✅ RESOLVED: #{error.exception_class}"
  else count.in?([10, 100, 1_000]) ? "#{subject} (#{count.ordinalize} occurrence)" : subject
  end
}

That covers wording, emoji, and with email_every_occurrence = true things like marking the 100th occurrence. Counting up to the occurrence's id, as above, gives the same number however late the mail job runs.

Emails for an app's own events. With the lifecycle notifications from #107, an app can send the error email for events Solid Errors doesn't email about itself. Examples are an error being resolved, or one occurring more often than usual (a rate spike). Whatever reason the app passes to error_occurred reaches the proc, so those emails get their own subjects too:

ActiveSupport::Notifications.subscribe("error_resolved.solid_errors") do |event|
  occurrence = event.payload[:error].occurrences.last
  SolidErrors::ErrorMailer.error_occurred(occurrence, :resolved).deliver_later if occurrence && SolidErrors.send_emails?
end

This is why reason is documented as open-ended. Solid Errors itself only ever passes :created, :reopened or nil.

How

The occurrence already knows whether it opened its error (opens_error). That attribute isn't persisted, though, and deliver_later loads the occurrence again by GlobalID, so the mailer would never see it. The occurrence now passes it to the mailer as an optional second argument, and the mailer hands it to the proc:

ErrorMailer.error_occurred(self, opens_error).deliver_later

error_occurred(occurrence) still works unchanged, so apps that call the mailer directly or override it are unaffected.

If the setting is more than you want

The "(reopened)" fix doesn't depend on the proc. If you'd rather not take on email_subject, I'm happy to cut this back to just the default subject change.

Tests

• The default subject, with and without :reopened.
• A custom proc gets the error, the occurrence and the reason, and the prefix is still added to its result.
• A reason passed by the app, such as :resolved, reaches the proc.
• Reporting an error again after it was resolved enqueues the email with :reopened. This test fails without the change to Occurrence.