Taskiq.py

🚀 New issue to taskiq-python/taskiq by @juanmicl 📝 A schedule with an invalid cron_offset string crashes the whole scheduler (#668) Taskiq version 0.12.6 (master) Python version Python 3.12 OS Linux What happened? is_cron_task_now in taskiq/cli/scheduler/run.py calls ZoneInfo(offset) outside the try block that converts ValueError into CronValueError, and SchedulerLoop._is_schedule_ready_to_send only catches CronValueError. A cron_offset that is not a valid IANA key raises ZoneInfoNotFoundError (a KeyError subclass) that escapes SchedulerLoop.run and kills the scheduler process. One malformed schedule stops all scheduling until the process is restarted. from datetime import datetime, timezone from taskiq.cli.scheduler.run import SchedulerLoop from taskiq.scheduler.scheduled_task import ScheduledTask loop = SchedulerLoop.__new__(SchedulerLoop) loop.cron_tasks_last_run = {} loop.interval_tasks_last_run = {} loop.time_tasks_last_run = {} task = ScheduledTask( task_name="mod:cleanup", labels={}, args=[], kwargs={}, cron="* * * * *", cron_offset="UTC+3", # natural spelling, but not an IANA key ) loop._is_schedule_ready_to_send(task=task, now=datetime.now(tz=timezone.utc)) # -> zoneinfo.ZoneInfoNotFoundError escapes and kills SchedulerLoop.run An invalid offset should get the same treatment as an invalid cron expression: log a warning and skip that schedule, keeping the loop alive. The original timezone-offset request (#201) proposed per-schedule offsets as strings like "+3" and "-1", so this spelling is a natural thing for users to write. This is a different bug from #605 / #625. That change restores timedelta offsets from their serialized ISO-8601 form at model-validation time and does not touch run.py. A plain invalid timezone string still reaches ZoneInfo() at runtime. With the #625 patch applied, cron_offset="UTC+3" still crashes the loop, because parse_cron_offset leaves the string untouched (it is not a valid duration either). Relevant log output zoneinfo._common.ZoneInfoNotFoundError: 'No time zone found with key UTC+3' Broker initialization code Not needed. The repro calls the scheduler loop directly. #bug sent via relator