starred/asynq

Fork 0

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

[GH-ISSUE #264] [FEATURE REQUEST] Ability to add task's state as optional parameter for uniquekey #2123

New issue

Closed

opened 2026-03-15 19:16:16 +03:00 by kerem · 4 comments

kerem commented

2026-03-15 19:16:16 +03:00

Owner

Originally created by @nilam-sorathia on GitHub (Apr 23, 2021).
Original GitHub issue: https://github.com/hibiken/asynq/issues/264

Originally assigned to: @hibiken on GitHub.

Is your feature request related to a problem? Please describe.
The current processing task receives a duplicate task error when attempting to enqueue the next task with the same payload with the unique option.

Describe the solution you'd like
I would like to set the task's current state as an optional parameter included in the uniquekey and constraint check so that the current task that is 'active' can schedule the next task as 'scheduled'.

Describe alternatives you've considered
I am currently scheduling the next task in a new goroutine which sleeps for a few seconds giving the current handler time to complete and return.

Originally created by @nilam-sorathia on GitHub (Apr 23, 2021). Original GitHub issue: https://github.com/hibiken/asynq/issues/264 Originally assigned to: @hibiken on GitHub. **Is your feature request related to a problem? Please describe.** The current processing task receives a duplicate task error when attempting to enqueue the next task with the same payload with the unique option. **Describe the solution you'd like** I would like to set the task's current state as an optional parameter included in the uniquekey and constraint check so that the current task that is 'active' can schedule the next task as 'scheduled'. **Describe alternatives you've considered** I am currently scheduling the next task in a new goroutine which sleeps for a few seconds giving the current handler time to complete and return.

kerem

2026-03-15 19:16:16 +03:00

closed this issue
added the
enhancement
label

kerem commented

2026-03-15 19:16:33 +03:00

Author

Owner

@hibiken commented on GitHub (Apr 24, 2021):

@nilam-sorathia Thank you for opening this issue!

Let me make sure that I understood your use case correctly;
Are you enqueueing a task with the same type and payload within the Handler(Effectively creating a loop)? Also, why do you need to use the Unique option for these tasks?

@hibiken commented on GitHub (Apr 24, 2021): @nilam-sorathia Thank you for opening this issue! Let me make sure that I understood your use case correctly; Are you enqueueing a task with the same type and payload within the `Handler`(Effectively creating a loop)? Also, why do you need to use the `Unique` option for these tasks?

kerem commented

2026-03-15 19:16:38 +03:00

Author

Owner

@nilam-sorathia commented on GitHub (Apr 24, 2021):

Thank you for creating this library, and asynqmon, which we also use. Its clean, well documented, and easy to use. Much appreciated!

Thats correct, we are creating a loop. We are enqueuing a job for each tenant, and the work that the job does is expensive (calling external services with api limits, etc..), and some tenants have a lot more work and take much longer to process than others, from minutes to hours. These jobs are enqueued from another service/api that could be called more than once, thus we want to ensure that there is only a single job for each tenant, hence the Unique option.

@nilam-sorathia commented on GitHub (Apr 24, 2021): Thank you for creating this library, and `asynqmon`, which we also use. Its clean, well documented, and easy to use. Much appreciated! Thats correct, we are creating a loop. We are enqueuing a job for each tenant, and the work that the job does is expensive (calling external services with api limits, etc..), and some tenants have a lot more work and take much longer to process than others, from minutes to hours. These jobs are enqueued from another service/api that could be called more than once, thus we want to ensure that there is only a single job for each tenant, hence the `Unique` option.

kerem commented

2026-03-15 19:16:43 +03:00

Author

Owner

@hibiken commented on GitHub (Apr 24, 2021):

Thank you!
I see. I may have a solution if I understood your situation correctly.

Is it possible to only use the Unique option when enqueueing tasks from the service that may be called more than once to ensure the uniqueness, but within the task Handler, since we already ensured that the task is in question is already unique, we can re-enqueue again without specifying the Unique option (If you omit the option, unique check won't be applied).

Does that make sense in your case? Let me know if that still doesn't solve the problem!

@hibiken commented on GitHub (Apr 24, 2021): Thank you! I see. I may have a solution if I understood your situation correctly. Is it possible to only use the `Unique` option when enqueueing tasks from the service that may be called more than once to ensure the uniqueness, but within the task `Handler`, since we already ensured that the task is in question is already unique, we can re-enqueue again without specifying the `Unique` option (If you omit the option, unique check won't be applied). Does that make sense in your case? Let me know if that still doesn't solve the problem!

kerem commented

2026-03-15 19:16:48 +03:00

Author

Owner

@nilam-sorathia commented on GitHub (Apr 24, 2021):

Yes, your proposed solution will address our use case. I appreciate your time @hibiken.

@nilam-sorathia commented on GitHub (Apr 24, 2021): Yes, your proposed solution will address our use case. I appreciate your time @hibiken.

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

No description provided.

Rows
Columns