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

max_retries seems a bit restrictive, design-wise #38

Open
miracle2k opened this issue Jan 12, 2014 · 0 comments
Open

max_retries seems a bit restrictive, design-wise #38

miracle2k opened this issue Jan 12, 2014 · 0 comments

Comments

@miracle2k
Copy link

If I want a progressive delay logic, i.e. incrementally increasing delay time, I need to do this myself in the worker when calling retry(). I might want to limit the retry by time (30 days) rather than count.

Given that, it doesn't make sense to me that the worker must worry about the producer not queuing up the job with the correct number of retries. I basically say max_retries=99999 now, which is ugly.

What I'd like to see is the retry() command gaining an option that allows users to skip the default max_retries logic, and allow the worker to decide if the retries have been exhausted.

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

1 participant