[GH-ISSUE #1001] [FEATURE REQUEST] About custom retry... #2506

New issue

Open

opened 2026-03-15 20:44:24 +03:00 by kerem · 1 comment

kerem commented

2026-03-15 20:44:24 +03:00

Owner

Originally created by @Flipped199 on GitHub (Jan 3, 2025).
Original GitHub issue: https://github.com/hibiken/asynq/issues/1001

Originally assigned to: @hibiken, @kamikazechaser on GitHub.

Hello,

I’ve been using Asynq and I think it’s an excellent library! However, I have a small question regarding its design, specifically about the retry strategy. I noticed that the retry configuration seems to be set globally at the server level. While I understand that tasks can be distinguished by their Type(), I was wondering why custom retry options aren’t designed to be configured directly on the task itself. Wouldn’t this make it more flexible and easier to use?

Thank you for your time!

Originally created by @Flipped199 on GitHub (Jan 3, 2025). Original GitHub issue: https://github.com/hibiken/asynq/issues/1001 Originally assigned to: @hibiken, @kamikazechaser on GitHub. Hello, I’ve been using Asynq and I think it’s an excellent library! However, I have a small question regarding its design, specifically about the retry strategy. I noticed that the retry configuration seems to be set globally at the server level. While I understand that tasks can be distinguished by their Type(), I was wondering why custom retry options aren’t designed to be configured directly on the task itself. Wouldn’t this make it more flexible and easier to use? Thank you for your time!

kerem added the

enhancement

label

2026-03-15 20:44:24 +03:00

kerem commented

2026-03-15 20:44:35 +03:00

Author

Owner

@armistcxy commented on GitHub (Mar 5, 2025):

According to me, having a centralized place as RetryDelayFunc is much easier when you want to modify how to calculate delay for each of them

For example I have two categories for task (each category might contain more than one type of task) and I want to calculate delay for each of them

srv := asynq.NewServer(redis, asynq.Config{
    RetryDelayFunc: func(n int, e error, t *asynq.Task) time.Duration {
        switch {
        case isFetchTask(t.Type()):
            return expBackoff(n)
        case isInsertTask(t.Type()):
            return linearBackoff(n)
        default:
            return asynq.DefaultRetryDelayFunc(n, e, t)
        }
    },
})

If you want more specific set up for each task, use option asynq.ProcessIn or asynq.ProcessAt

@armistcxy commented on GitHub (Mar 5, 2025): According to me, having a centralized place as `RetryDelayFunc` is much easier when you want to modify how to calculate delay for each of them For example I have two categories for task (each category might contain more than one type of task) and I want to calculate delay for each of them ```go srv := asynq.NewServer(redis, asynq.Config{ RetryDelayFunc: func(n int, e error, t *asynq.Task) time.Duration { switch { case isFetchTask(t.Type()): return expBackoff(n) case isInsertTask(t.Type()): return linearBackoff(n) default: return asynq.DefaultRetryDelayFunc(n, e, t) } }, }) ``` If you want more specific set up for each task, use option `asynq.ProcessIn` or `asynq.ProcessAt`

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

starred/asynq#2506

No description provided.

Rows
Columns