starred/asynq

Fork 0

mirror of https://github.com/hibiken/asynq.git synced 2026-04-25 23:15:51 +03:00

[GH-ISSUE #968] [FEATURE REQUEST] Allow cancelling task without retrying it #2492

New issue

Open

opened 2026-03-15 20:41:07 +03:00 by kerem · 3 comments

kerem commented

2026-03-15 20:41:07 +03:00

Owner

Originally created by @faleksic on GitHub (Nov 13, 2024).
Original GitHub issue: https://github.com/hibiken/asynq/issues/968

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

I want to cancel a task without asynq retrying it. I've tried to return asynq.SkipRetry error from the handler when context is canceled, but currently Asynq processor will ignore it and pass context error ctx.Err() to the handleFailedMessage function and my error is ignored.

I wish there is a way to call inspector.CancelProcessing(taskID) and skip retrying that specific task. I am trying to implement a feature where a client can give up on running some task and simply cancel it.

One idea to bypass this issue is to set MaxRetry to 0 and that way it wouldn't be retried, but then the task wouldn't be retried in any other case. How I currently bypassed this issue is that keep my own version of Cancellations and before running the task I create a different context instead of passing the one given to me by Asynq. That way, I am able to handle the cancel event and return asynq.SkipRetry to not retry it again. Asynq is not aware that the task is canceled

Originally created by @faleksic on GitHub (Nov 13, 2024). Original GitHub issue: https://github.com/hibiken/asynq/issues/968 Originally assigned to: @hibiken, @kamikazechaser on GitHub. I want to cancel a task without asynq retrying it. I've tried to return `asynq.SkipRetry` error from the handler when context is canceled, but currently Asynq processor will ignore it and pass context error `ctx.Err()` to the `handleFailedMessage` function and my error is ignored. I wish there is a way to call `inspector.CancelProcessing(taskID)` and skip retrying that specific task. I am trying to implement a feature where a client can give up on running some task and simply cancel it. One idea to bypass this issue is to set `MaxRetry` to 0 and that way it wouldn't be retried, but then the task wouldn't be retried in any other case. How I currently bypassed this issue is that keep my own version of `Cancellations` and before running the task I create a different context instead of passing the one given to me by Asynq. That way, I am able to handle the cancel event and return `asynq.SkipRetry` to not retry it again. Asynq is not aware that the task is canceled

kerem added the

enhancement

label

2026-03-15 20:41:07 +03:00

kerem commented

2026-03-15 20:41:18 +03:00

Author

Owner

@kamikazechaser commented on GitHub (Nov 14, 2024):

This would be a good feature to have. One way is to handle the context.Cancelled error case and archive the task. The problem is that would be a breaking change because most of the users are used to the fact that any job that has its context cancelled will be retried (current behavior).

We could add an option of archiveOnCancel (bool) to the server which would then archive the task upon context cancellation or if false, retry it (default).

An extra good to have feature would also be to access the Cancellations map directly from the client so that you don't have to cancel through Redis pub/sub which is unreliable.

Also btw, in theory, you could register a custom error handler and archive the task with the inspector to achieve the same effect. Maybe i'll test it and document it in the wiki.

@kamikazechaser commented on GitHub (Nov 14, 2024): This would be a good feature to have. One way is to handle the `context.Cancelled` error case and archive the task. The problem is that would be a breaking change because most of the users are used to the fact that any job that has its context cancelled will be retried (current behavior). We could add an option of `archiveOnCancel (bool)` to the server which would then archive the task upon context cancellation or if false, retry it (default). An extra good to have feature would also be to access the `Cancellations` map directly from the client so that you don't have to cancel through Redis pub/sub which is unreliable. Also btw, in theory, you could register a custom error handler and archive the task with the inspector to achieve the same effect. Maybe i'll test it and document it in the wiki. Related: * #532 * #599 * #420 * #799

kerem commented

2026-03-15 20:41:23 +03:00

Author

Owner

@kamikazechaser commented on GitHub (Nov 14, 2024):

Could you try something like this and pass it to the server Config ErrorHandler and report back.

type CancellationsHandler struct {
    inspector *asynq.Inspector
}

func (h *CancellationsHandler) HandleError(ctx context.Context, t *asyq.Task, err error) {
    if errors.Is(err, context.Cancelled) {
          return h.inspector.Archive(...)
    }
}

@kamikazechaser commented on GitHub (Nov 14, 2024): Could you try something like this and pass it to the server Config ErrorHandler and report back. ```go type CancellationsHandler struct { inspector *asynq.Inspector } func (h *CancellationsHandler) HandleError(ctx context.Context, t *asyq.Task, err error) { if errors.Is(err, context.Cancelled) { return h.inspector.Archive(...) } } ```

kerem commented

2026-03-15 20:41:29 +03:00

Author

Owner

@faleksic commented on GitHub (Nov 14, 2024):

Just tried it, unfortunately it doesn't work. I get the following error cannot archive task in active state. use CancelProcessing instead.

@faleksic commented on GitHub (Nov 14, 2024): Just tried it, unfortunately it doesn't work. I get the following error `cannot archive task in active state. use CancelProcessing instead.`

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

No description provided.

Rows
Columns