Is your feature request related to a problem?
TaskIQ creates event loops internally in both CLI execution paths:
- worker subprocesses call
asyncio.new_event_loop()
- the scheduler calls
asyncio.run()
Applications that require a specific event loop implementation cannot provide one. One example is async Psycopg on Windows, which cannot run on the default ProactorEventLoop and requires a selector-based loop.
A process-wide event loop policy can currently work around this, but asyncio policies are deprecated in Python 3.14 and scheduled for removal in Python 3.16. Hardcoding WindowsSelectorEventLoopPolicy, as proposed in #641, would therefore solve only the worker case and depend on an API that is already being removed.
Describe the solution you'd like
Add an optional --loop-factory module:callable option to both taskiq worker and taskiq scheduler.
The imported callable should return an asyncio.AbstractEventLoop.
For workers, the factory should be resolved inside each worker subprocess and take precedence over automatic uvloop selection. For the scheduler, it should be passed to the scheduler runner. Existing behavior should remain unchanged when the option is omitted.
Examples:
taskiq worker app:broker --loop-factory app.loops:selector_loop_factory
taskiq scheduler app:scheduler --loop-factory app.loops:selector_loop_factory
Describe alternatives you've considered
- Setting a process-wide asyncio event loop policy. This is deprecated in Python 3.14 and scheduled for removal in Python 3.16.
- Automatically forcing a selector policy on Windows. This changes the default globally, covers only one platform, and still relies on the deprecated policy API.
- Reimplementing TaskIQ's worker or scheduler launchers in application code. This duplicates TaskIQ's process supervision and CLI behavior.
Which component would this affect?
Configuration
Is your feature request related to a problem?
TaskIQ creates event loops internally in both CLI execution paths:
asyncio.new_event_loop()asyncio.run()Applications that require a specific event loop implementation cannot provide one. One example is async Psycopg on Windows, which cannot run on the default
ProactorEventLoopand requires a selector-based loop.A process-wide event loop policy can currently work around this, but asyncio policies are deprecated in Python 3.14 and scheduled for removal in Python 3.16. Hardcoding
WindowsSelectorEventLoopPolicy, as proposed in #641, would therefore solve only the worker case and depend on an API that is already being removed.Describe the solution you'd like
Add an optional
--loop-factory module:callableoption to bothtaskiq workerandtaskiq scheduler.The imported callable should return an
asyncio.AbstractEventLoop.For workers, the factory should be resolved inside each worker subprocess and take precedence over automatic uvloop selection. For the scheduler, it should be passed to the scheduler runner. Existing behavior should remain unchanged when the option is omitted.
Examples:
Describe alternatives you've considered
Which component would this affect?
Configuration