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

Add Sidekiq support #63

Closed
mperham opened this issue Feb 2, 2014 · 8 comments
Closed

Add Sidekiq support #63

mperham opened this issue Feb 2, 2014 · 8 comments

Comments

@mperham
Copy link

mperham commented Feb 2, 2014

I'm going to drop native support for error handlers in Sidekiq 3.0, so as to not play favorites and give each error service full control over their own implementation. This includes Honeybadger so you'll need to ship your own Sidekiq 3.0 support.

To be clear, I'll be removing this line:

https://github.com/mperham/sidekiq/blob/master/lib/sidekiq/exception_handler.rb#L13

BugSnag has a sample implementation for their integration here:

https://github.com/bugsnag/bugsnag-ruby/blob/master/lib/bugsnag/sidekiq.rb

3.0 has no set release date so you should have plenty of time.

@joshuap
Copy link
Member

joshuap commented Feb 3, 2014

I'm on it, thanks!

@mperham
Copy link
Author

mperham commented Mar 1, 2014

Sidekiq 3.0 is now on master. You'll want to review this:

https://github.com/mperham/sidekiq/blob/master/Upgrading.md#error-service-providers

joshuap pushed a commit that referenced this issue Mar 11, 2014
In response to #63, this commit adds reporting of exceptions which happen in Sidekiq processes. The new error_handler API is used so that all exceptions are reported, not just those which occur during job execution:

https://github.com/mperham/sidekiq/blob/master/Upgrading.md#error-service-providers

A server middleware is also added in order to clear the Honeybadger context hash after each job executes. Because earlier versions of Sidekiq had native support for reporting exceptions but did not clear the context hash, the middleware and error handler are installed separately; all Sidekiq versions get the middleware, but only >= 3.0.0 get the error handler.
@joshuap
Copy link
Member

joshuap commented Mar 11, 2014

@mperham mind checking that commit (c3ac638)? I'll be doing some integration testing; we use Appraisals, but I have yet to find a good way to test against every combination of every gem we support. Is v3 stable enough for production yet?

@mperham
Copy link
Author

mperham commented Mar 11, 2014

@joshuap I think you might have a problem. The error handler isn't called until the error trickles all the way back up the stack to the Processor. By this time your middleware would have already executed and cleared the context. Maybe your error handler should clear the context after calling notify_or_ignore and skip the middleware?

@mperham
Copy link
Author

mperham commented Mar 11, 2014

I know of people already using 3.0 (aka the master branch) in production but we're not and I still think of master as not production quality yet. That said, I don't know of any problems with it.

@joshuap
Copy link
Member

joshuap commented Mar 12, 2014

Ah, good point. The problem with clearing the context in the error handler block is that it is only invoked when an error occurs, which would not be every job. Ideally the context would be specific to each job, since you wouldn't want data for multiple jobs being sent for a single exception. Can you think of a way to accomplish that? If not, I guess clearing it in the error handler would be better than nothing.

@mperham
Copy link
Author

mperham commented Mar 12, 2014

Clear it at the START of a new job. :-)

On Wed, Mar 12, 2014 at 8:16 AM, joshuap notifications@github.com wrote:

Ah, good point. The problem with clearing the context in the error handler
block is that it is only invoked when an error occurs, which would not be
every job. Ideally the context would be specific to each job, since you
wouldn't want data for multiple jobs being sent for a single exception. Can
you think of a way to accomplish that? If not, I guess clearing it in the
error handler would be better than nothing.

Reply to this email directly or view it on GitHubhttps://github.com//issues/63#issuecomment-37420387
.

@joshuap
Copy link
Member

joshuap commented Mar 12, 2014

Heh. This is why we pay you the big bucks. :)

joshuap pushed a commit that referenced this issue Mar 13, 2014
Per #63, This prevents the context from being cleared before the error handler can report it (which happens up the stack, and isn't always job-specific).
@joshuap joshuap closed this as completed May 15, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants