Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly
Appearance settings

Add max retry check in task rejection to prevent infinite requeue (WIP) #9642

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.

Sign up for GitHub

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

Jump to bottom
Draft
wants to merge 3 commits into
base: main
Choose a base branch
Loading
from
Draft

Add max retry check in task rejection to prevent infinite requeue (WIP) #9642

wants to merge 3 commits into from

Conversation

sandeep-kesarwani
Copy link

@sandeep-kesarwani sandeep-kesarwani commented Mar 28, 2025 •
edited
Loading

Fix: Limit Rejected Task Retries to Prevent Infinite Loops

Problem

Currently, when a task is rejected with requeue=True, it will be retried indefinitely without any limit. This can lead to infinite message loops if there's a persistent issue that cannot be resolved, potentially causing system resource exhaustion.

Solution

Added rejection tracking and max retries handling to the Request class to prevent infinite rejection loops:

  1. Added _rejection_count to track number of rejections per task
  2. Enhanced reject() method to respect task's max_retries setting
  3. When max retries exceeded:
    • Task is rejected without requeue
    • Marked as failed in backend with MaxRetriesExceededError
    • Warning is logged

Example

@app.task(bind=True, max_retries=3)
def my_task(self):
    try:
        result = do_something()
    except Exception as exc:
        # Will now respect max_retries=3
        raise Reject(exc, requeue=True)

Backward Compatibility

  • If max_retries is not set on the task, behavior remains unchanged
  • Only applies retry limit when max_retries is explicitly set

Related Issues (WIP)

Fixes #XXXX (if there's an existing issue)

Documentation

This change improves task reliability by preventing infinite rejection loops while maintaining backward compatibility. Users can now safely use Reject(requeue=True) with max_retries to control retry behavior.

@sandeep-kesarwani sandeep-kesarwani changed the title Add max retry check in task rejection to prevent infinite requeue Add max retry check in task rejection to prevent infinite requeue (WIP) Mar 28, 2025
@auvipy auvipy requested review from Copilot and auvipy March 29, 2025 09:03
Copilot
Copilot AI reviewed Mar 29, 2025
View reviewed changes
Copy link
Contributor

@Copilot Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull Request Overview

This PR adds logic to limit the number of task requeues by tracking rejection counts and enforcing a maximum retry limit to prevent infinite loops.

  • Added a _rejection_count attribute to the Request class.
  • Extended the slots for Request to include _rejection_count.
  • Updated the reject() method to increment the rejection count, compare it with max_retries, and mark the task as failed when the limit is exceeded.

celery/worker/request.py Outdated Show resolved Hide resolved
@auvipy @Copilot
Update celery/worker/request.py
a77a28d 
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
@auvipy
Copy link
Member

auvipy commented Mar 29, 2025

can you please also link the related issues?

@Nusnus Nusnus self-requested a review March 30, 2025 16:44
@chrisbarber
Copy link

After exceeding the retries, will the task on_failure method end up getting invoked?

We would like to direct failures (including worker lost and hard timeout) to failure queues on redis that are not listened to, sort of like dead letter.

I was also considering that there could be an option in Celery to specify a queue to requeue into when rejecting, rather than requeuing always to the same one. But if this change will mean we can access the task during on_failure then we can do a retry from there to a specific queue and not lose anything if the failure was part of a chain etc.

@chrisbarber
Copy link

After exceeding the retries, will the task on_failure method end up getting invoked?

We would like to direct failures (including worker lost and hard timeout) to failure queues on redis that are not listened to, sort of like dead letter.

I was also considering that there could be an option in Celery to specify a queue to requeue into when rejecting, rather than requeuing always to the same one. But if this change will mean we can access the task during on_failure then we can do a retry from there to a specific queue and not lose anything if the failure was part of a chain etc.

I tested by applying the body of the reject method from this PR to an overridden (custom) Request class.

The rejection count comes back as always 0 i.e. this PR seems to have no effect / not do what it claims to.

Nor does unconditionally running the mark_as_failure section (as if the rejection count had been exceeded) run the task on_failure method as I was interested in.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

Copilot code review Copilot Copilot left review comments

@auvipy auvipy Awaiting requested review from auvipy

@Nusnus Nusnus Awaiting requested review from Nusnus

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
3 participants
@sandeep-kesarwani @auvipy @chrisbarber
Morty Proxy This is a proxified and sanitized view of the page, visit original site.