Taskiq.py

Да, короче это всё из-за kuberay, как я полагаю.

Hey there Полина, and welcome to Taskiq.py! How are you?

🚀 New issue to taskiq-python/taskiq by @tavallaie 📝 Add PGMQ support / broker (#662) Is your feature request related to a problem? Existing Postgres brokers for taskiq use custom tables + LISTEN/NOTIFY. PGMQ is a real message queue on Postgres (visibility timeout, delay, archive/delete, etc.) with a Python SDK, and there's no broker for it yet. Describe the solution you'd like A taskiq broker backed by PGMQ, similar to the other broker packages. Happy to help implement it. • PGMQ: https://github.com/pgmq/pgmq • Python SDK: https://github.com/pgmq/pgmq-py Describe alternatives you've considered No response Which component would this affect? Broker #enhancement sent via relator

🚀 New issue to taskiq-python/taskiq by @juanmicl 📝 Worker misparses positional arguments when a preceding parameter lacks a type annotation (#666) Taskiq version Taskiq version 0.12.6 (master) Python version Python 3.12 OS Linux What happened? parse_params in taskiq/receiver/params_parser.py maps positional arguments to annotations with a counter (argnum) that only increments for annotated parameters. Unannotated parameters are skipped with continue before argnum += 1, but get_type_hints() omits them too, so they still occupy a slot in message.args. When any positional parameter has no annotation, every argument after it is parsed against the wrong annotation. Example: @broker.task async def my_task(request_id, count: int) -> None: ... await my_task.kiq("12345", 3) What the worker receives (verified on master, taskiq 0.12.6): 1. request_id arrives as the int 12345. The unannotated parameter's value is coerced by the next parameter's annotation. 2. count is never validated. kiq("hello", "not-an-int") delivers "not-an-int" to count, and the only log line is a Can't parse argument 0 warning about the other parameter. 3. If the first value fails to parse, the annotated parameter after it never gets coerced either. It keeps its wire representation, so a datetime parameter receives an ISO string. 4. *values: int varargs coerce only the first element. kiq("1", "2", "3") arrives as [1, "2", "3"]. Standalone repro of the worker path, no broker needed: import inspect from typing import get_type_hints from taskiq.formatters.json_formatter import JSONFormatter from taskiq.message import TaskiqMessage from taskiq.receiver.params_parser import parse_params fmt = JSONFormatter() def my_task(request_id, count: int) -> None: ... msg = fmt.loads(fmt.dumps(TaskiqMessage( task_id="1", task_name="mod:my_task", labels={}, labels_types={}, args=["12345", 3], kwargs={}, )).message) parse_params(inspect.signature(my_task), get_type_hints(my_task),

🚀 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)