Allow Sidekiq jobs with remaining retries to not notify. (#781)

[brettburley]

This prevents specific exceptions from being notifying when there are remaining retries left on a job in the Sidekiq integration. For example, you might configure with:

Raven.configure do |config|
  config.retryable_exceptions = [HTTP::TimeoutError, Errno::ECONNRESET]
end

See #781 for more details.

Any suggestions as to how I could test with the "Sidekiq full-stack integration" part of the sidekiq spec? In particular, it doesn't appear that the Raven configuration is reset between tests, and other tests don't perform a Raven.configure, so I'm not sure how bad it would be to set configuration in the spec to add a test retryable_exception.

[brettburley]

These changes fail two lint rules:

1. Assignment Branch Condition size for initialize is too high, can we just increase this from 30 to ~32? Otherwise, I'm not sure if there's a better place to put this configuration.
2. Class has too many lines, not sure if you're OK increasing this limit as well, or if we should try pulling out some of the common functionality. For example, retryable_exception? and excluded_exception? share logic using get_exception_class, which we could pull out into a util or similar.

[nateberkopec]

I think this sort of behavior can already be accomplished with should_capture. I'll write up an example and put it in the docs.

[brettburley]

@nateberkopec good point. Looking at the implementation of should_capture, it looks like it's only currently passed the exception itself, and not the additional options added to capture_exception in the Sidekiq exception handler. However, that information is tagged on Raven.extra_context[:sidekiq] -- would you recommend just reading it from there within the capture handler?

[gingerlime]

@brettburley thanks for the PR. curious how you managed to resolve this eventually? I bumped into the same problem, and want to find a way to log errors to sentry, but not every retry, but perhaps only if it fails for at least X retries... I guess with should_capture and digging into the extra sidekiq context, I can do something, but it feels a bit cumbersome for something that should evaluate quickly, and also, as @nateberkopec commented on before, shouldn't this really be part of the sidekiq integration?

[gingerlime]

@brettburley sorry for nagging, but would really appreciate if you could share some more details here.

[gingerlime]

Rollbar seems to do this with a configurable sidekiq_threshold

[krisleech]

I too think it would be preferable to have non-reporting of retried exceptions built in to the sidekiq integration.

[marcsasson]

I think this sort of behavior can already be accomplished with should_capture. I'll write up an example and put it in the docs.

@nateberkopec Can you link to where you wrote an example or can provide one?

[seanlinsley]

Is there a reason not to use death_handlers? It seems to do all the heavy lifting, and since 2018 has covered all job types: sidekiq/sidekiq#3980

[st0012]

closed because sentry-raven has entered maintenance mode and won't receive any enhancement