[GH-ISSUE #756] Error callback handler when a task exhausted the retries limit #371

New issue

Open

opened 2026-03-02 05:20:45 +03:00 by kerem · 1 comment

kerem commented

2026-03-02 05:20:45 +03:00

Owner

Originally created by @khun84 on GitHub (Oct 5, 2023).
Original GitHub issue: https://github.com/hibiken/asynq/issues/756

Im would like to execute a callback when a task has exhausted all its retry limit. The closet I could find is the error predicate handler func. However the retry info wasnt exposed by this func.

Do we have this feature in asynq?

Originally created by @khun84 on GitHub (Oct 5, 2023). Original GitHub issue: https://github.com/hibiken/asynq/issues/756 Im would like to execute a callback when a task has exhausted all its retry limit. The closet I could find is the error predicate handler func. However the retry info wasnt exposed by this func. Do we have this feature in asynq?

kerem commented

2026-03-02 05:20:46 +03:00

Author

Owner

@ghstahl commented on GitHub (Jan 2, 2024):

I would like this as well. However, I would like to see the retry info being exposed directly to the handler.

When you call the task handler also send operational information like.
MaxRetries
CurrentRetry
etc

The use case for me is so that I can eat the error on the last retry and return a nil error. There are some cases where I DO NOT want the tasks going to the archive. I am tracking that information in my own db.

I have tasks that are LOW value, HIGH frequency and I don't care if they succeed in the END.
There are tasks that are HIGH value, LOW frequency that I may let go to the archive queue.

If my archive fills up with junk that I don't care about then it isn't useful and just a waste of resources.

@ghstahl commented on GitHub (Jan 2, 2024): I would like this as well. However, I would like to see the retry info being exposed directly to the handler. When you call the task handler also send operational information like. MaxRetries CurrentRetry etc The use case for me is so that I can eat the error on the last retry and return a nil error. There are some cases where I DO NOT want the tasks going to the archive. I am tracking that information in my own db. I have tasks that are **LOW** value, **HIGH** frequency and I don't care if they succeed in the END. There are tasks that are **HIGH** value, **LOW** frequency that I may let go to the archive queue. If my archive fills up with junk that I don't care about then it isn't useful and just a waste of resources.