CODEWITHSUNDEEP
djangocelery
whatWhat
whatWhat

Reputation: 4067

Django Celery retry() task but continue with current task

I have a situation where I receive a response from a third party service indicating that my initial request failed and that I should retry. I'm calling the service in a Celery task. The retry call isn't captured in an exception and it seems that instead of giving a new instance of the task to the broker and continuing with the current task it gives the task to the broker and exits the task. Is there any way to set a retry and continue with the current task?

Upvotes: 0

Views: 2298

Answers (2)

bhuvan-rk
bhuvan-rk

Reputation: 21

My code is slightly different. In this case, I have a celery task that loops through a list of receivers to send a message. If any of the send calls fail, I dont want the celery task to exit, but instead continue with the other receivers.

This does not happen with task.retry(throw=False) in my case. I do see the task exiting at that point without doing blah. 

@celery_app.task()
def send_msg_to_list():
    for recvr in Emailrecvr.objects.filter(query=obj):
        try:
            email_rv = recvr.send(msg)
        except SMTPException:
            # Dont exit the loop but continue with others 
            send_msg_to_list.retry(throw=False)
    # do some blah here

Upvotes: 0

asksol
asksol

Reputation: 19499

task.retry raises the RetryTaskError exception, which is used to detect that the task was retried. See the note here: http://docs.celeryproject.org/en/latest/userguide/tasks.html#retrying-a-task-if-something-fails

You can skip this behavior by using throw=False:

task.retry(throw=False)
# do something else
raise RetryTaskError(None, None)

if you don't raise the exception the current task will not be marked as in the RETRY state, but in the SUCCESS/FAILURE states depending on if the rest of the task succeeds or not. Since the retry task will share the same uuid as the current task, the current task could override the result of the new task if the new task returns before the current task. This of course, does not matter if you ignore the results of the task anyway.

Does that make sense?

Upvotes: 2

Related Questions