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

The number of attempts before notifications will be sent. #1632

Open
manme opened this issue Nov 30, 2021 · 7 comments
Open

The number of attempts before notifications will be sent. #1632

manme opened this issue Nov 30, 2021 · 7 comments
Assignees
Milestone

Comments

@manme
Copy link

manme commented Nov 30, 2021

Describe the idea

I would like to have the option: attempt_threshold - the number of attempts before notifications will be sent.
The option: report_after_job_retries - is a boolean and does not allow to send a notifications after N retry.

Why do you think it's beneficial to most of the users

The user will receive a notification after the third retry because it could be solved automatically (external service was not available or similar), no more spam notifications.

Possible implementation

Similar to https://github.com/honeybadger-io/honeybadger-ruby/blob/master/lib/honeybadger/plugins/sidekiq.rb#L43

@st0012
Copy link
Collaborator

st0012 commented Dec 5, 2021

#1570 looks pretty similar to what you propose here but with more detail. Would you say it matches your expectation?

@manme
Copy link
Author

manme commented Dec 5, 2021

Thanks for your response. As I understand, #1570 does not solve my problem: I want to get a notification in Sentry from a job that has failed N times (not on a first attempt) where N < sidekiq retry. For example, I get a notification after the third attempt, and the job will stay in Retries (with a default retry value of 25). Then as a developer, I have time to fix the bug and won't receive notification from jobs that failed because of network problems as it's not a bug, just a temporary issue.

@st0012
Copy link
Collaborator

st0012 commented Dec 19, 2021

@manme I see. What'll happen after the first report then? In your example, the SDK should send the event after the 4th retry failed, right?. After that, should it send events for the 5th, 6th...etc. failures?

@st0012 st0012 added this to the 5.0.0 milestone Dec 19, 2021
@renchap
Copy link

renchap commented Dec 19, 2021

I agree with the initial author, this would be very useful, especially for jobs depending on an external service and/or unreliable network, where it is not a problem if the job is retried for a few times.

I would expect all failures after the threshold to be sent to Sentry.

@st0012 st0012 modified the milestones: 5.0.0, 6.0.0 Jan 7, 2022
@github-actions
Copy link

This issue has gone three weeks without activity. In another week, I will close it.

But! If you comment or otherwise update it, I will reset the clock, and if you label it Status: Backlog or Status: In Progress, I will leave it alone ... forever!


"A weed is but an unloved flower." ― Ella Wheeler Wilcox 🥀

@Sam-Killgallon
Copy link

👍 I was just looking for this exact feature as well with the same use case.

We integrate with a third party and a small percentage of requests fail and then succeed on the second retry due to things outside our control. I'd ideally like to be able to set a threshold on the job level, so that each job could be configured separately.

@benhutton
Copy link

yes! I was about to submit a request for the exact same feature. I want the first one or two or N retries to NOT send anything to sentry, because that means that the error is a network error and is recovered quickly. I want all of the rest of the errors sent.

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

7 participants