Incorrect count for attempts upon ultimate failure?

[christopherraa]

Incorrect count for attempts upon ultimate failure?

[christopherraa]

Thinking about this further it seems like attempts has three distinct meanings:

• before performing task: "how many times the jobs is to be attempted before transitioning to a failed state"
• during task execution: "remaining attempts before giving up"
• after transitioning to failed: "indication that the task had one initial attempt"

[kraih]

Happy to consider a PR.

[christopherraa]

I'm a bit usure what would be the "correct" behaviour and even a solution that could be accepted. The way I see this issue it is hard to solve it witout introducing breaking changes in some way.

The simplest solution that I can think of would be to let attempts reach zero when the last attempt is done and make sure that the documentation clearly say that attempts denotes "the number of remaining attempts".

Another solution would be to make a distinction between "the number of attempts each job is configured with" and "the number of remaining attempts". This can be achieved by adding a new property of the job that hold the number of attempts that was initially configured for the job, which would not change during job execution / retries. Naming is hard but names such as total_attempts, attempt_limit or something of the sort could be considered. attempts would then still signify "the number of remaining attempts" and would at time of enqueue() be set to the same value as attempt_limit, which whould default to 1 to keep things similar to how it is today. In any case I think I would like to see attempts hit zero once all attempts were exhausted. The reason I'd like to see this separation of fields is that with this solution none of them would change what they signify during the job lifetime.

Do you have any thoughts or preferences here?