starred/asynq

Fork 0

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

[GH-ISSUE #91] [FEATURE REQUEST] Create tasks without timestamp #26

New issue

Closed

opened 2026-03-02 05:18:01 +03:00 by kerem · 5 comments

kerem commented

2026-03-02 05:18:01 +03:00

Owner

Originally created by @gunnsth on GitHub (Feb 18, 2020).
Original GitHub issue: https://github.com/hibiken/asynq/issues/91

Originally assigned to: @hibiken on GitHub.

Is your feature request related to a problem? Please describe.
Sometimes I don't really want to schedule a task. Just want it to get processed as soon as possible (next slot ready). It feels a bit awkward to need to provide a timestamp for that, even if time.Now() will work in most cases (assuming that the clocks are well synchronized - which normally would not be a problem).

Describe the solution you'd like
Would be nice if could do something like:

err := client.ScheduleNext(t)

and the task would be processed in next available slot without any time dependence.

Describe alternatives you've considered
Using time.Now() is currently the way to go. But as I mentioned, any time differences can lead to delay in processing. In many cases the goal is to have tasks processed right away, in which case any possible delays are not desirable.

Additional context
Basically came from my feeling of using the library. I could be wrong here or not understand fully how the internals handle the timing. In that case, the documentation could be improved a bit to clarify.

Originally created by @gunnsth on GitHub (Feb 18, 2020). Original GitHub issue: https://github.com/hibiken/asynq/issues/91 Originally assigned to: @hibiken on GitHub. **Is your feature request related to a problem? Please describe.** Sometimes I don't really want to schedule a task. Just want it to get processed as soon as possible (next slot ready). It feels a bit awkward to need to provide a timestamp for that, even if time.Now() will work in most cases (assuming that the clocks are well synchronized - which normally would not be a problem). **Describe the solution you'd like** Would be nice if could do something like: ```go err := client.ScheduleNext(t) ``` and the task would be processed in next available slot without any time dependence. **Describe alternatives you've considered** Using `time.Now()` is currently the way to go. But as I mentioned, any time differences can lead to delay in processing. In many cases the goal is to have tasks processed right away, in which case any possible delays are not desirable. **Additional context** Basically came from my feeling of using the library. I could be wrong here or not understand fully how the internals handle the timing. In that case, the documentation could be improved a bit to clarify.

kerem

2026-03-02 05:18:01 +03:00

closed this issue
added the
enhancement

good first issue
labels

kerem commented

2026-03-02 05:18:02 +03:00

Author

Owner

@hibiken commented on GitHub (Feb 19, 2020):

Thanks for this feedback!

As described in Life of a Task, when you call

client.Schedule(task, time.Now())

Task will be enqueued immediately to a queue (FIFO queue) and will be dequeued by a worker as soon as it gets to the front of the queue.

My initial thought behind exporting just one method from the Client type was to keep the API surface area as small as possible.

But, I completely agree that we can provide better API to do what's effectively done with

client.Schedule(task, timestamp)

In fact, I've been thinking about changing this Client API for the last few weeks myself.
Here's my proposal for the Client API

// Process task immediately 
client.Enqueue(task)

// Process at the specified time
client.EnqueueAt(task, timestamp)

// Process after specified duration
client.EnqueueIn(task, duration)

This is similar to python's RQ library's API.

Let me know your thoughts.

@hibiken commented on GitHub (Feb 19, 2020): Thanks for this feedback! As described in [Life of a Task](https://github.com/hibiken/asynq/wiki/Life-of-a-Task), when you call ```go client.Schedule(task, time.Now()) ``` Task will be enqueued immediately to a queue (FIFO queue) and will be dequeued by a worker as soon as it gets to the front of the queue. My initial thought behind exporting just one method from the `Client` type was to keep the API surface area as small as possible. **But, I completely agree that we can provide better API** to do what's effectively done with ```go client.Schedule(task, timestamp) ``` In fact, I've been thinking about changing this Client API for the last few weeks myself. Here's my proposal for the `Client` API ```go // Process task immediately client.Enqueue(task) ``` ```go // Process at the specified time client.EnqueueAt(task, timestamp) ``` ```go // Process after specified duration client.EnqueueIn(task, duration) ``` This is similar to python's [RQ library's API](https://python-rq.org/docs/scheduling/). Let me know your thoughts.

kerem commented

2026-03-02 05:18:02 +03:00

Author

Owner

@gunnsth commented on GitHub (Feb 19, 2020):

Yes that sounds great.

@gunnsth commented on GitHub (Feb 19, 2020): Yes that sounds great.

kerem commented

2026-03-02 05:18:02 +03:00

Author

Owner

@hibiken commented on GitHub (Feb 19, 2020):

@gunnsth Would you like to work on this?

@hibiken commented on GitHub (Feb 19, 2020): @gunnsth Would you like to work on this?

kerem commented

2026-03-02 05:18:02 +03:00

Author

Owner

@gunnsth commented on GitHub (Feb 19, 2020):

@hibiken Sure. I can take a look at it. Need to familiarize myself a bit with the internals first and best ways for debugging. Should be fun. Might take a while though as I am pretty swamped at the moment.

@gunnsth commented on GitHub (Feb 19, 2020): @hibiken Sure. I can take a look at it. Need to familiarize myself a bit with the internals first and best ways for debugging. Should be fun. Might take a while though as I am pretty swamped at the moment.

kerem commented

2026-03-02 05:18:03 +03:00

Author

Owner

@hibiken commented on GitHub (Feb 20, 2020):

No pressure! Feel free to ping me on gitter channel if you have questions 😄

@hibiken commented on GitHub (Feb 20, 2020): No pressure! Feel free to ping me on [gitter channel](https://gitter.im/go-asynq/community) if you have questions 😄

kerem referenced this issue

2026-03-07 22:04:09 +03:00

[GH-ISSUE #26] Re-evaluate retry count semantics #1019

kerem referenced this issue

2026-03-15 18:51:18 +03:00

[GH-ISSUE #26] Re-evaluate retry count semantics #2030

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

No description provided.

Rows
Columns