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.
Taskiq version
0.12.6 (master)
Python version
Python 3.12
OS
Linux
What happened?
is_cron_task_nowintaskiq/cli/scheduler/run.pycallsZoneInfo(offset)outside thetryblock that convertsValueErrorintoCronValueError, andSchedulerLoop._is_schedule_ready_to_sendonly catchesCronValueError. Acron_offsetthat is not a valid IANA key raisesZoneInfoNotFoundError(aKeyErrorsubclass) that escapesSchedulerLoop.runand kills the scheduler process. One malformed schedule stops all scheduling until the process is restarted.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
timedeltaoffsets from their serialized ISO-8601 form at model-validation time and does not touchrun.py. A plain invalid timezone string still reachesZoneInfo()at runtime. With the #625 patch applied,cron_offset="UTC+3"still crashes the loop, becauseparse_cron_offsetleaves 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