Skip to content

A schedule with an invalid cron_offset string crashes the whole scheduler #668

Description

@juanmicl

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't working

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions