Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

exq integration #54

Closed
joshuap opened this issue Aug 22, 2016 · 6 comments
Closed

exq integration #54

joshuap opened this issue Aug 22, 2016 · 6 comments

Comments

@joshuap
Copy link
Member

joshuap commented Aug 22, 2016

This integration would automatically report exceptions from failed exq jobs, similar to how we do for Ruby/Sidekiq. See akira/exq#191 for a potential solution. We should also investigate if the current use_logger option already works for this case.

@rbishop
Copy link
Contributor

rbishop commented Aug 22, 2016

I've had this discussion pop up a few other times about other background job libraries in Elixir. In general the problem I've noticed is that most of them are designed like Ruby libraries and not like Erlang/Elixir libraries. What I mean is that when an exception occurs they rescue it and do their cleanup. If they were to re-raise after cleanup then the process will crash and the error logger will be automatically notified.

@schneidmaster
Copy link

I confirmed that use_logger does not work with exq. I wrote a very simple middleware that ought to do the trick, but haven't tested it yet since the change to make the exception struct available in exq middleware hasn't yet landed in a stable release.

@schneidmaster
Copy link

Two other notes on exq middleware --

  • It must be declared in config.exs in addition to the default exq middleware; i.e. you need middleware: [Exq.Middleware.Stats, Exq.Middleware.Job, Exq.Middleware.Manager, Exq.Middleware.Logger, Exq.Middleware.Honeybadger] or else the Stats, Job, etc. won't run. AFAIK there's no way to declare "extra" middleware without re-declaring the default list.
  • The before_work and after_processed_work methods are required in all exq middleware even if they just return the unadulterated pipeline

@joshuap
Copy link
Member Author

joshuap commented Aug 25, 2016

@schneidmaster thanks! We'll keep an eye on the exq release so that we can potentially package an error-handling middleware with honeybadger.

@sorentwo
Copy link
Collaborator

There are more than a handful of background job processors out there now: exq, verk, ecto_job, honeydew, kiq. There isn't an obvious favorite to support like there is with plug and phoenix.

I don't believe it is tenable to support middleware for all of these projects inside of Honeybadger itself (not to mention how easy it is to integrate Honeybadger manually).

@joshuap What do you think? Can we close this out?

@joshuap
Copy link
Member Author

joshuap commented Nov 2, 2018

@sorentwo yep, thanks!

@joshuap joshuap closed this as completed Nov 2, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants