starred/asynq

Fork 0

mirror of https://github.com/hibiken/asynq.git synced 2026-04-26 15:35:55 +03:00

[GH-ISSUE #842] [QUESTION] Archived periodic tasks are not triggered on the scheduled run #2435

New issue

Open

opened 2026-03-15 20:29:50 +03:00 by kerem · 5 comments

kerem commented

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

Owner

Originally created by @sgavinio on GitHub (Mar 14, 2024).
Original GitHub issue: https://github.com/hibiken/asynq/issues/842

Originally assigned to: @hibiken on GitHub.

Describe the issue

Hello 👋

When following the advise given here: https://github.com/hibiken/asynq/discussions/376 to specify a fixed task ID to avoid duplicate periodic tasks when having multiple scheduler instances, for example:

task := asynq.NewTask(name, payload,  asynq.TaskID("foo"), asynq.Retention(time.Minute))
_, err := scheduler.Register("* * * * *", task)

Periodic tasks that error out are simply moved to the archived state and are never again triggered on the next schedule.

I can confirm this doesn't happen if the TaskID() option is not specified. Similar to the linked discussion above, we have the scheduler running together with the worker, and where we can have potentially any number of workers depending on the amount of available work.

The only way I've managed to get the task to start again on the next schedule is to manually delete the task (i.e. remove it from archived so it can be re-enqueued again).

We write our background tasks to be completely idempotent so simply running a failed task on the next scheduled run is perfectly fine for us.

Would there be a way to skip the failed periodic tasks from going to archived? It would be ideal if an option similar to Retention() exists (which as I understand only works for completed tasks) for archived tasks.

Originally created by @sgavinio on GitHub (Mar 14, 2024). Original GitHub issue: https://github.com/hibiken/asynq/issues/842 Originally assigned to: @hibiken on GitHub. **Describe the issue** Hello 👋 When following the advise given here: https://github.com/hibiken/asynq/discussions/376 to specify a fixed task ID to avoid duplicate periodic tasks when having multiple scheduler instances, for example: ```golang task := asynq.NewTask(name, payload, asynq.TaskID("foo"), asynq.Retention(time.Minute)) _, err := scheduler.Register("* * * * *", task) ``` Periodic tasks that error out are simply moved to the `archived` state and are never again triggered on the next schedule. I can confirm this doesn't happen if the `TaskID()` option is not specified. Similar to the linked discussion above, we have the scheduler running together with the worker, and where we can have potentially any number of workers depending on the amount of available work. The only way I've managed to get the task to start again on the next schedule is to manually delete the task (i.e. remove it from archived so it can be re-enqueued again). We write our background tasks to be completely idempotent so simply running a failed task on the next scheduled run is perfectly fine for us. Would there be a way to skip the failed periodic tasks from going to `archived`? It would be ideal if an option similar to `Retention()` exists (which as I understand only works for `completed` tasks) for archived tasks.

kerem added the

enhancement

label

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

kerem commented

2026-03-15 20:30:01 +03:00

Author

Owner

@JeremyCraven commented on GitHub (Oct 26, 2024):

This would be really nice.

@JeremyCraven commented on GitHub (Oct 26, 2024): This would be really nice.

kerem commented

2026-03-15 20:30:06 +03:00

Author

Owner

@exfly commented on GitHub (Nov 27, 2024):

Also encountered this problem. Can tasks that enter the achived state not be considered conflicts?

@exfly commented on GitHub (Nov 27, 2024): Also encountered this problem. Can tasks that enter the achived state not be considered conflicts?

kerem commented

2026-03-15 20:30:11 +03:00

Author

Owner

@kamikazechaser commented on GitHub (Dec 3, 2024):

What version are you on?

@kamikazechaser commented on GitHub (Dec 3, 2024): What version are you on?

kerem commented

2026-03-15 20:30:16 +03:00

Author

Owner

@JeremyCraven commented on GitHub (Dec 3, 2024):

I was encountering this on v0.24.1

@JeremyCraven commented on GitHub (Dec 3, 2024): I was encountering this on `v0.24.1`

kerem commented

2026-03-15 20:30:21 +03:00

Author

Owner

@kamikazechaser commented on GitHub (Dec 4, 2024):

Could you try and repro it on v0.25.0?

@kamikazechaser commented on GitHub (Dec 4, 2024): Could you try and repro it on v0.25.0?

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

No description provided.

Rows
Columns