Checklist

• I have checked the issues list
  for similar or identical enhancement to an existing feature.
• I have checked the pull requests list
  for existing proposed enhancements.
• I have checked the commit log
  to find out if the if the same enhancement was already implemented in the
  master branch.
• I have included all related issues and possible duplicate issues in this issue
  (If there are none, check this box anyway).

Related Issues and Possible Duplicates

Related Issues

• Retry tasks which failed because of SIGKILL #5106 feels like it may be fixed by this as well, but I'm not sure that it fixes their exact issue
• Document and code are inconsistent about task_reject_on_worker_lost config #5598 mentions that the docs don't describe this redelivered behavior

Possible Duplicates

• None

Brief Summary

If task_acks_late and task_reject_on_worker_lost are set, a task will be requeued the first time it fails due to losing a worker. However if the message has the redelivered flag set to True, requeue will be set to false. That means a second worker lost failure doesn't get retried.

We're running on Heroku and it's possible we'll get workers killed back to back if we release new code and then do a config change right after, as one example. We'd like to continue to requeue the task regardless of the redelivered flag.

Design

Architectural Considerations

None

Proposed Behavior

Add a configuration flag task_requeue_on_redelivered that if set to True, causes the task to be requeued regardless of the redelivered flag.

I'm happy to put together a PR to do this if it seems like a reasonable approach.

Proposed UI/UX

Diagrams

N/A

Alternatives

The way we work around this now is by overriding Request and always setting redelivered to False:

class NeverRedeliveredRequest(Request):
    def __init__(self, message, **kwargs):
        if message.delivery_info:
            message.delivery_info['redelivered'] = False
        super().__init__(message, **kwargs)

I don't like obliterating information that might be used elsewhere though, so I'd prefer this to be in Celery itself.