starred/asynq

Fork 0

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

[GH-ISSUE #179] [FEATURE REQUEST] Trackable UID for publishing events #1071

New issue

Closed

opened 2026-03-07 22:05:12 +03:00 by kerem · 1 comment

kerem commented

2026-03-07 22:05:12 +03:00

Owner

Originally created by @xkortex on GitHub (Jul 3, 2020).
Original GitHub issue: https://github.com/hibiken/asynq/issues/179

Originally assigned to: @hibiken on GitHub.

Is your feature request related to a problem? Please describe.
Currently, tasks are "fire and forget". There is no way to check on a particular task once it's been enqueued. I can think of several instances where you may want to perform different logic if a task fails / times out (without getting into a full-blown scheduler of course!)

Example use case: for exeq jobs, I'd like to notify the client UI if something causes the job to bounce too many times. Usually this means something is misconfigured.

Describe the solution you'd like
There are a few possible ways to solve this.

Add an Option which lets the caller of Enqueue specify the ID to use, overriding xid.New().
Add new argument to Enqueue to specify the ID to use, overrIding xid.
Put a ID field in struct Task. Empty string passed to Enqueue results in xid.New().
Return the value generated by client submission. This would change the signature to Enqueue(t *Task, opts ...Option) (id string, err error).
some combo of 2 and 4, with a new EnqueueID(t * Task, id string, opts ...) (id string, err error)

Pros/cons:

Pros: gives you more granular control over ID generation. Cons: Doesn't really fit with the idea of "options". Lets user potentially shoot themselves in the foot
Pros: granular. Cons: more clutter if you just want random ID. Footgun.
Pros: clean, seems logical that the same conceptual Task should have the same ID. Cons: Footgun.
Pros: Feels most idiomatic. Probably a good idea even in case of 1/2. Cons: bigger API change than adding a field to a struct. Will result in lots of _, err := Enqueue() if people don't care and just want random.
meh, probably the most lackluster option. Extra code.

All 5 would require SOME api change, so that is a con for all, though that is the nice part about being in v0.*. But that might be the right move in the long run anyways. The common theme with anything allowing the user to set the ID is flexibility in exchange for possibility of setting off duplicate IDs and shooting themselves in the foot.

Describe alternatives you've considered
some gross reflection hacks to figure out the most recent job submitted 🤷

Originally created by @xkortex on GitHub (Jul 3, 2020). Original GitHub issue: https://github.com/hibiken/asynq/issues/179 Originally assigned to: @hibiken on GitHub. **Is your feature request related to a problem? Please describe.** Currently, tasks are "fire and forget". There is no way to check on a particular task once it's been enqueued. I can think of several instances where you may want to perform different logic if a task fails / times out (without getting into a full-blown scheduler of course!) Example use case: for exeq jobs, I'd like to notify the client UI if something causes the job to bounce too many times. Usually this means something is misconfigured. **Describe the solution you'd like** There are a few possible ways to solve this. 1) Add an `Option` which lets the caller of `Enqueue` specify the ID to use, overriding xid.New(). 2) Add new argument to Enqueue to specify the ID to use, overrIding xid. 3) Put a ID field in `struct Task`. Empty string passed to Enqueue results in `xid.New()`. 4) Return the value generated by [client submission](https://github.com/hibiken/asynq/blob/4e5f5969108de59ffd2574471cd2e3399a2f4914/client.go#L225). This would change the signature to `Enqueue(t *Task, opts ...Option) (id string, err error)`. 5) some combo of 2 and 4, with a new `EnqueueID(t * Task, id string, opts ...) (id string, err error)` Pros/cons: 1) Pros: gives you more granular control over ID generation. Cons: Doesn't really fit with the idea of "options". Lets user potentially shoot themselves in the foot 2) Pros: granular. Cons: more clutter if you just want random ID. Footgun. 3) Pros: clean, seems logical that the same conceptual Task should have the same ID. Cons: Footgun. 4) Pros: Feels most idiomatic. Probably a good idea even in case of 1/2. Cons: bigger API change than adding a field to a struct. Will result in lots of `_, err := Enqueue()` if people don't care and just want random. 5) meh, probably the most lackluster option. Extra code. All 5 would require SOME api change, so that is a con for all, though that is the nice part about being in v0.*. But that might be the right move in the long run anyways. The common theme with anything allowing the user to set the ID is flexibility in exchange for possibility of setting off duplicate IDs and shooting themselves in the foot. **Describe alternatives you've considered** some gross reflection hacks to figure out the most recent job submitted 🤷

kerem

2026-03-07 22:05:12 +03:00

closed this issue
added the
enhancement
label

kerem commented

2026-03-07 22:05:14 +03:00

Author

Owner

@hibiken commented on GitHub (Jul 3, 2020):

@xkortex Thanks for opening this issue!

#178 will resolve this issue. It's similar to 4 approach you suggested above.
Let me know if you have thoughts on the new API.

Thanks!

@hibiken commented on GitHub (Jul 3, 2020): @xkortex Thanks for opening this issue! #178 will resolve this issue. It's similar to 4 approach you suggested above. Let me know if you have thoughts on the new API. Thanks!

kerem referenced this issue

2026-03-07 22:10:58 +03:00

[GH-ISSUE #1071] [BUG] Some tasks are processed prior to scheduled time #1524

kerem referenced this issue

2026-03-15 20:48:39 +03:00

[GH-ISSUE #1071] [BUG] Some tasks are processed prior to scheduled time #2533

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

No description provided.

Rows
Columns