starred/asynq

Fork 0

mirror of https://github.com/hibiken/asynq.git synced 2026-04-26 07:25:56 +03:00

[GH-ISSUE #472] [FEATURE REQUEST] Self-Managed Retries #2240

New issue

Closed

opened 2026-03-15 19:49:06 +03:00 by kerem · 7 comments

kerem commented

2026-03-15 19:49:06 +03:00

Owner

Originally created by @AlexCuse on GitHub (May 17, 2022).
Original GitHub issue: https://github.com/hibiken/asynq/issues/472

Originally assigned to: @hibiken on GitHub.

Is your feature request related to a problem? Please describe.
I would like to be able to leverage "processor managed" retries for specific tasks running through an asynq server.

Describe the solution you'd like
I will have a PR shortly for a SelfManagedRetry option that will override Retry/Retried logic to retry a task indefinitely (from asynq's perspective) allowing the processor to terminate by either returning success or SkipRetry.

Describe alternatives you've considered
Looked at the options around "consuming retry count" and thought about figuring considered setting a high number of retries since looking at this within a fairly short expiration right now but came around to favoring something a little more direct.

There is a risk of tasks retrying indefinitely if not self-managed correctly but this should be difficult to fall into without using the option.

Originally created by @AlexCuse on GitHub (May 17, 2022). Original GitHub issue: https://github.com/hibiken/asynq/issues/472 Originally assigned to: @hibiken on GitHub. **Is your feature request related to a problem? Please describe.** I would like to be able to leverage "processor managed" retries for specific tasks running through an asynq server. **Describe the solution you'd like** I will have a PR shortly for a `SelfManagedRetry` option that will override Retry/Retried logic to retry a task indefinitely (from asynq's perspective) allowing the processor to terminate by either returning success or SkipRetry. **Describe alternatives you've considered** Looked at the options around "consuming retry count" and thought about figuring considered setting a high number of retries since looking at this within a fairly short expiration right now but came around to favoring something a little more direct. There is a risk of tasks retrying indefinitely if not self-managed correctly but this should be difficult to fall into without using the option.

kerem

2026-03-15 19:49:06 +03:00

closed this issue
added the
enhancement
label

kerem commented

2026-03-15 19:49:22 +03:00

Author

Owner

@hibiken commented on GitHub (May 18, 2022):

@AlexCuse Thank you for creating an issue.

Have you taken a look at Config.IsFailure?
You can provide this function to determine whether the error returned from the Handler should be considered a failure. Non-failure error won't consume the retry count; You can leverage this feature to try task indefinitely if you so choose.

See this wiki for more info (https://github.com/hibiken/asynq/wiki/Task-Retry#non-failure-error)

@hibiken commented on GitHub (May 18, 2022): @AlexCuse Thank you for creating an issue. Have you taken a look at [`Config.IsFailure`](https://pkg.go.dev/github.com/hibiken/asynq#Config.IsFailure)? You can provide this function to determine whether the error returned from the `Handler` should be considered a failure. Non-failure error won't consume the retry count; You can leverage this feature to try task indefinitely if you so choose. See this wiki for more info (https://github.com/hibiken/asynq/wiki/Task-Retry#non-failure-error)

kerem commented

2026-03-15 19:49:27 +03:00

Author

Owner

@AlexCuse commented on GitHub (May 18, 2022):

I have looked at it @hibiken - the problem with most of what is there is that its not task type specific. We have a subset of critical tasks that are "chained" so to speak and we really only want to change the behavior for those tasks - the idea is to retry up to an expiration that is encoded in the task payloads, and once the expiration is hit to move the task into a cancellation queue where processors will clean up any progress associated with the attempt.

Maybe another option could be to make the existing methods task-type aware?

@AlexCuse commented on GitHub (May 18, 2022): I have looked at it @hibiken - the problem with most of what is there is that its not task type specific. We have a subset of critical tasks that are "chained" so to speak and we really only want to change the behavior for those tasks - the idea is to retry up to an expiration that is encoded in the task payloads, and once the expiration is hit to move the task into a cancellation queue where processors will clean up any progress associated with the attempt. Maybe another option could be to make the existing methods task-type aware?

kerem commented

2026-03-15 19:49:32 +03:00

Author

Owner

@hibiken commented on GitHub (May 18, 2022):

Can you define your own error type and include task type?

e.g.

type TaskError struct {
    TaskType string
    // ... other metadata 
}

func (e *TaskError) Error() string { /* ... */ }

func IsFailure(err error) bool {
    taskErr, ok := err.(*TaskError)
    if !ok {
        return true // other errors are always considered failures
    }
    switch taskErr.TaskType {
    case "foo":
        // ... handle each task type differently       
    }
}

@hibiken commented on GitHub (May 18, 2022): Can you define your own error type and include task type? e.g. ```go type TaskError struct { TaskType string // ... other metadata } func (e *TaskError) Error() string { /* ... */ } func IsFailure(err error) bool { taskErr, ok := err.(*TaskError) if !ok { return true // other errors are always considered failures } switch taskErr.TaskType { case "foo": // ... handle each task type differently } }

kerem commented

2026-03-15 19:49:37 +03:00

Author

Owner

@AlexCuse commented on GitHub (May 18, 2022):

We could I'm not sure how attractive it is as the number of registered processors in the system grows though. Will think a bit about how far this could get us.

@AlexCuse commented on GitHub (May 18, 2022): We could I'm not sure how attractive it is as the number of registered processors in the system grows though. Will think a bit about how far this could get us.

kerem commented

2026-03-15 19:49:42 +03:00

Author

Owner

@AlexCuse commented on GitHub (May 18, 2022):

@hibiken it occurs to me thinking about this that a custom IsFailure func registered with the processor could be preferable to the additional option in some (most?) ways. I will look into ways this could be achieved but is that something that might be more attractive than a task level option?

@AlexCuse commented on GitHub (May 18, 2022): @hibiken it occurs to me thinking about this that a custom `IsFailure` func registered with the processor could be preferable to the additional option in some (most?) ways. I will look into ways this could be achieved but is that something that might be more attractive than a task level option?

kerem commented

2026-03-15 19:49:47 +03:00

Author

Owner

@hibiken commented on GitHub (May 18, 2022):

I believe the options we offer now (MaxRetry option and IsFailure callback) are generic enough to accommodate most use cases. I don't see adding a new option to further customize retry logic.

@hibiken commented on GitHub (May 18, 2022): I believe the options we offer now (`MaxRetry` option and `IsFailure` callback) are generic enough to accommodate most use cases. I don't see adding a new option to further customize retry logic.

kerem commented

2026-03-15 19:49:52 +03:00

Author

Owner

@AlexCuse commented on GitHub (May 19, 2022):

Thanks for the quick response @hibiken i disagree but we will be able to muddle through with what's there for awhile. I have already changed the code and will probably open the PR anyway once I've tested it in a running system in case you change your mind, seems like a pretty simple change.

@AlexCuse commented on GitHub (May 19, 2022): Thanks for the quick response @hibiken i disagree but we will be able to muddle through with what's there for awhile. I have already changed the code and will probably open the PR anyway once I've tested it in a running system in case you change your mind, seems like a pretty simple change.

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#2240

No description provided.

Rows
Columns