Failure backend

[ono]

The change allows you to implement/configure custom job failure backends.

config :task_bunny, failure_backend: [
  TaskBunny.FailureBackend.Logger,
  YourApp.CustomFailureBackend
]

This will allow you to send the error report to your choice of services such as Rollbar, Airbrake, Bugsnag, Raygun etc... with the richer information.

We are also planning to release Rollbar backend as a separate hex library sometime in the next week.

[elliotthilaire]

typo: implement

[IanLuites]

Great job! 👍 Looks really good, can't wait to use it and debug those errors!

I do want to mention that the following files miss @spec for the public functions:

• lib/task_bunny/failure_backend/logger.ex
• lib/task_bunny/job_error.ex

[IanLuites]

I think that if you put TaskBunny.FailureBackend.Logger between backticks that ExDoc will pick up on the module and make it linkable.

Ref: Auto-Linking

[IanLuites]

Not really necessary, the result of Enum.each/2 is already :ok. (Isn't that bad either.)

[IanLuites]

More an option suggestion, I know your preference, so I'm just putting it out there, because it will align the triple-quotes nicely.

If you like it you can also write:

"""
TaskBunny - #{error.job} failed for an invalid return value.

Return value:
#{my_inspect error.return_value}

#{common_message error}
"""
|> do_report(error.reject)

(You know how I love aligning and pipes 😛)

[IanLuites]

The value of :job is defined as only atom, so it might be nicer to write :job, here in stead of job: nil. (Because that would be a default that is technically not allowed by the spec.)

If you go for :job then I would also add @enforce_keys [:job] so it also does not default to nil.

The same goes for :pid and turning it into @enforce_keys [:job, :pid].