[GH-ISSUE #1090] [Feature Request] Support for Group-based Sequential Processing (Serialization by Key) #2550

New issue

Open

opened 2026-03-15 20:50:13 +03:00 by kerem · 0 comments

kerem commented

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

Owner

Originally created by @nhd98z on GitHub (Feb 5, 2026).
Original GitHub issue: https://github.com/hibiken/asynq/issues/1090

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

Is your feature request related to a problem? Please describe.
I'm facing a race condition issue when processing tasks that share a specific resource constraint (e.g., tasks affecting the same wallet_address and chain_id).

Currently, asynq allows controlling global concurrency, but it doesn't seem to support "Partitioned Concurrency"—where tasks are executed sequentially per entity (same key) but concurrently across different entities.

For example:

Task A1 and Task A2 (both for User A) are enqueued.
Task B1 (for User B) is enqueued.
I want Task B1 to run in parallel with Task A1.
However, Task A2 must wait until Task A1 completes.

Currently, if multiple workers pick up Task A1 and Task A2 simultaneously, we encounter state conflicts.

Describe the solution you'd like
I would like to propose adding a Group or SerializationKey option when enqueuing a task.
The scheduler/processor should ensure that for any given Key, only one task is being processed at a time across all workers.

Originally created by @nhd98z on GitHub (Feb 5, 2026). Original GitHub issue: https://github.com/hibiken/asynq/issues/1090 Originally assigned to: @hibiken, @kamikazechaser on GitHub. **Is your feature request related to a problem? Please describe.** I'm facing a race condition issue when processing tasks that share a specific resource constraint (e.g., tasks affecting the same `wallet_address` and `chain_id`). Currently, `asynq` allows controlling global concurrency, but it doesn't seem to support "Partitioned Concurrency"—where tasks are executed sequentially *per entity* (same key) but concurrently *across different entities*. For example: - Task A1 and Task A2 (both for User A) are enqueued. - Task B1 (for User B) is enqueued. - I want Task B1 to run in parallel with Task A1. - However, Task A2 **must wait** until Task A1 completes. Currently, if multiple workers pick up Task A1 and Task A2 simultaneously, we encounter state conflicts. **Describe the solution you'd like** I would like to propose adding a `Group` or `SerializationKey` option when enqueuing a task. The scheduler/processor should ensure that for any given `Key`, only **one** task is being processed at a time across all workers.

kerem added the

enhancement

label

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

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

No description provided.

Rows
Columns