New feature ideas

[s3rius]

Here we want to discuss new feature Ideas we want to see in taskiq.

[devraj]

Healthcheck

The general idea is to provide a way to get a healthcheck from the broker. I start this thread where it would be nice to be able to ask the broker if things are health. It in turn check for the backends (as configured by the application)

[s3rius]

I guess, that along with this feature it would be nice to add ability to shut down if any worker exits more than several times.

[s3rius]

I started with implementing the max-restarts option, since it easier and can be used as healthcheck. The PR is #190. The main idea is that if broker loses connection, it raises an exception and fails the process. After several restarts. Taskiq can decide to kill all other processes.

[suspiciousRaccoon]

Interval based schedules

My current use case requires that tasks be executed in intervals set by a user. If I understood correctly the time parameter is only useful for one off tasks, and cron only has minutes as it's lowest value. Celery does this by allowing setting the schedule as seconds or a timedelta for more precise timings.

[s3rius]

It's a bit tricky to implement, and we actually had some attempts of implementing it, but couldn't make it right. We will add it some day for sure.

[so-saf]

This functionality has already been implemented in #498 and release in 0.12.0 version.

You can check updated docs about task scheduling here and here.

[pushpak1300]

Retry Jobs

There should be option to manually retry the job by some mechanism

cc: @s3rius

[s3rius]

What do you mean "manual retry". Can you please elaborate a little bit?

[pushpak1300]

if some job has been failed there should option to add failed jobs again in the queue by running some commands.

[francipvb]

A way to get job intermediate status

For example:

importtaskiq_redisimporttaskiq# ... Broker constructionbroker= ...
@broker.task()asyncdefmy_task(x: int)->int:
returnint*2job=awaitmy_task.find_job('job_id') # Same object returned when kickingassertjob.status==taskiq.JobStatus.RUNNINGschedule=awaitmy_task.get_schedule('schedule_id')
assertschedule.status==taskiq.ScheduleStatus.PENDINGassertschedule.status==taskiq.ScheduleStatus.KICKEDprint(schedule.next_time) # Calculated from cron expression or a raw datetime, if periodic or not kicked, `None` otherwise.

The schedule_id can be a None value for a periodic task, but for one-off schedules this should be a known value.

[s3rius]

The request with this functionality was merged recently It's available since 0.11.5.

[rafalkrupinski]

Hi
really awesome project - super simple to start with!

It would be nice to have worker-scoped generator dependencies.

I was kinda expecting generator dependencies to be this out of the box, based on experience with other projects.

This use case with dependency syntax

[LIghtJUNction]

Feature Request: Support Python 3.14 Subinterpreters for Running Workers

Hi Team,

With Python 3.14 significantly improving subinterpreter support (especially after PEP 684, which enables better memory isolation and shared resources between subinterpreters), I’m wondering if there’s a plan to add subinterpreters as a new executor option for running Taskiq workers.

Why this matters:

Compared to multiprocess workers: Subinterpreters are lighter (share part of the main process memory, e.g., core Python interpreter and read-only dependencies), reducing redundant memory overhead when scaling workers.
​
Compared to multithread workers: Each subinterpreter has its own GIL, enabling true parallelism (utilizing multiple CPU cores) without GIL bottlenecks—combining the best of both multiprocess (parallelism) and multithread (low memory) advantages.
Use case:

For scenarios where we need many workers (e.g., 10+), subinterpreters could balance performance and memory efficiency. For example, in a chatbot command-processing service, subinterpreters would avoid the high memory cost of 10+ independent processes while still leveraging for concurrent task execution.

Questions:

1. Is there any existing roadmap or technical blocker for supporting subinterpreters in Taskiq workers?
   ​
2. If this feature is feasible, would the team welcome contributions (e.g., a new SubinterpreterExecutor )?

Thanks for building such a great task queue tool!