Перейти к содержанию

Расписания (cron)

Планировщик Synth запускает задания по времени. Расписание не создаёт сессию само: оно публикует событие schedule_fired от источника cron, а дальше событие проходит обычную маршрутизацию (привязки и правила — События и автоматизация).

Как это работает

Cron-тик  ──▶ событие source:cron / type:schedule_fired ──▶ Router ──▶ сессия

Сообщение, которое получает агент, помечено автором Scheduler. В интерфейсе такое сообщение показывается отдельным уведомлением «Планировщик · <имя задания>».

Создание расписания

Расписание задаёт, когда и куда запускать:

Поле Назначение
name Имя задания (показывается в истории и уведомлениях)
enabled Включено ли расписание
cron Расписание в виде cron-выражения из пяти полей (UTC)
every Простой интервал: 30s, 15m, 1h, 24h (альтернатива cron)
target Куда направлять событие (см. ниже)
prompt Текст задания, который получает агент

Нужно задать ровно одно из cron / every. Например, каждый день в 9:00 UTC:

name: daily-report
enabled: true
cron: "0 9 * * *"
target:
  mode: bound
  sessionId: <session-id>
prompt: "Собери ежедневный отчёт по открытым задачам."

Куда направлять (target)

Режим Назначение
bound В постоянную сессию (sessionId)
queue В очередь существующей сессии (sessionId)
ephemeral В новую временную сессию; можно задать шаблон агента, проект и время жизни (ttl)
pipeline Запустить прогон пайплайна проекта (projectId + pipelineId)

Запуск пайплайна по расписанию

Режим pipeline отличается от остальных: он не создаёт сессию и не проходит обычную маршрутизацию событий — расписание напрямую запускает прогон пайплайна проекта.

name: nightly-report
enabled: true
cron: "0 2 * * *"
target:
  mode: pipeline
  projectId: <project-id>
  pipelineId: <pipeline-id>
  payload:
    period: week
Поле Назначение
projectId Проект-владелец пайплайна: прогон живёт в проекте
pipelineId Какой пайплайн запускать
version Зафиксировать версию пайплайна (необязательно) — по умолчанию берётся последняя опубликованная
payload Статические входные данные прогона: одинаковые при каждом срабатывании

В интерфейсе это цель «Пайплайн» во вкладке «Шедулер»: выберите проект, пайплайн и, при необходимости, входные данные в формате JSON.

Пайплайн должен быть опубликован

Запускается только опубликованная версия пайплайна. Черновик или неопубликованный пайплайн в списке будет помечен — и каждый запуск закончится ошибкой в истории заданий.

Прогон идёт в фоне. В истории срабатываний такая запись помечена решением «прогон пайплайна» и содержит идентификаторы пайплайна и прогона.

Пропущенные срабатывания (catch-up)

Если сервис был выключен и срабатывание пропущено, поведение задаёт scheduler.catchUp:

Режим Поведение
skip Пропуск фиксируется в истории, время следующего запуска пересчитывается
once Один «догоняющий» запуск с пометкой catchup

Расписание может переопределить это поле своим значением.

История срабатываний

История заданий доступна по GET /api/v2/schedules/:id/jobs (и во вкладке «Шедулер»). Каждая запись содержит:

  • trigger — cron, manual или catchup;
  • status — ok, error или skipped (с причиной, например «нет маршрута»);
  • время старта и окончания, длительность и id сессии.

Ручной запуск

Запустить задание немедленно, не дожидаясь расписания, можно кнопкой в интерфейсе или через POST /api/v2/schedules/:id/run. Событие при этом получает уникальный ключ дедупликации, поэтому не смешивается с плановым.

Управление

Расписания создаются, изменяются и удаляются в правой панели, вкладка «Шедулер» (доступна роли ADMIN), либо через API /api/v2/schedules.

Метод Путь Назначение
GET /api/v2/schedules Список расписаний
POST /api/v2/schedules Создать
PUT /api/v2/schedules/:id Обновить
DELETE /api/v2/schedules/:id Удалить
POST /api/v2/schedules/:id/run Запустить немедленно
GET /api/v2/schedules/:id/jobs История срабатываний

Настройка

Планировщик настраивается в конфигурации:

Параметр Назначение По умолчанию
scheduler.enabled Включён ли сервис (при false тикер не стартует, но CRUD и ручной запуск доступны) true
scheduler.tickSec Период тика, секунды 60
scheduler.catchUp Поведение при пропуске: skip или once skip
scheduler.jobRetentionDays Срок хранения истории заданий 30

Что дальше