Активация и версионирование

Workflow проходит через небольшой предсказуемый набор состояний. Эта страница объясняет, что значит каждое состояние, как превратить черновик в продакшен и как откатиться назад, когда нужно.

Жизненный цикл кратко

Под капотом у каждого workflow — один из пяти статусов:

Разрешённые переходы:

• blueprint → active_waiting (первая активация)
• active_waiting ⇄ active_running (исполнитель переключает это, когда запуски стартуют и завершаются)
• active_waiting / active_running → stopped или error
• stopped / error → active_waiting (реактивация)

В интерфейсе вы услышите слова «черновик», «активен» и «остановлен». Значения enum из БД — это то, что вы увидите в ответах API и в логах.

Публикация (активация)

Холст редактирует черновик; одна главная кнопка, чувствительная к триггеру, закрывает все сценарии публикации. Что именно на ней написано, зависит от того, выбран ли триггер и какого он типа.

Триггера ещё нет. На пустом холсте кнопка — Добавить триггер. Без выбранного триггера дальше двигаться нельзя.

Event-driven workflow (входящий webhook, расписание, polling-коннекторы вроде Telegram или Gmail) публикуется нажатием Запустить (в UI кнопка называется именно так, хотя по смыслу — «активировать»). Пока у черновика есть ошибки валидации, кнопка отключена — на тулбаре виден бейдж с их числом. Клик разворачивает черновик как новую неизменяемую версию И подключает триггер к внешнему миру (подписки на webhook становятся активными, Telegram-вебхуки настраиваются, polling-триггеры получают повторяющуюся BullMQ-задачу). Когда workflow уже активен, та же главная кнопка превращается в Остановить — она сворачивает внешнюю обвязку: вебхуки снимаются с регистрации (onDisable), задачи расписания удаляются, подписки помечаются неактивными. Остановленный workflow (в том числе авто-остановленный после повторных сбоев) можно снова активировать той же кнопкой.

Callable workflow (системный триггер manual — используется для действий AI-агентов и публикации workflow как действий) идёт по двухшаговому пути:

• При самом первом развёртывании главная кнопка — Запустить. Механика первого развёртывания такая же, как у event-driven (снапшот черновика, увеличение номера версии, валидация DAG), но подключать к внешнему миру нечего — callable-workflow вызывают агенты по запросу, а не внешние события.
• После первого развёртывания главная кнопка превращается в Опубликовать действие. Публикация снимает снапшот текущего черновика как новую версию и делает его видимым для list_actions, чтобы агенты могли его вызывать. Кнопка Опубликовать действие активна только если в workflow есть узел Return Output, — так у агентов есть определённая форма ответа. Рядом с ней живёт второстепенная кнопка Запустить вручную для разовых тестов во время итераций.

Ошибки валидации блокируют главную кнопку в любом сценарии. Сервис проверяет:

• Лимиты сложности — число узлов, число связей, глубина.
• Форма по типу — callable-workflow должен иметь ровно один узел Action Input и хотя бы один Return Output. event_driven-workflow должен иметь валидный узел триггера.

Если валидация не пройдена, развёртывание отклоняется, а тулбар показывает число проблем.

Старая кнопка Запустить и кнопки Launch/Stop на карточке workflow убраны — теперь главное действие целиком принадлежит тулбару холста. Правки черновика на уже активном event-driven workflow по-прежнему доступны: рядом с главной кнопкой появляются Применить изменения / Отменить изменения, позволяющие опубликовать черновик поверх работающей версии, не останавливая её.

Как активация доходит до внешнего мира. Для event-driven workflow Активировать — это не только снапшот версии. Под капотом вызывается activateTrigger(): регистрируются вебхуки, подписки inbound webhook помечаются активными, polling-задачи ставятся в BullMQ. Только после того как внешняя сторона отработает, workflow переходит в active_waiting. Остановить разворачивает всё это обратно.

Что именно версионируется

Версионированию подлежит только определение workflow — узлы, связи и конфигурация каждого узла, составляющие DAG. Каждое развёртывание создаёт строку workflow_versions со статусом deployed, предыдущие deployed/draft помечаются как archived, а при следующем редактировании создаётся свежая строка со статусом draft.

Учётные данные не снапшотятся. Узел, ссылающийся на подключение AmoCRM или Google, разрешает эти учётные данные во время запуска из таблицы connections. У этого есть осознанное следствие:

• Обновление учётных данных подключения действует немедленно на активной версии — повторное развёртывание не нужно.
• Откат workflow к старой версии не откатывает используемые учётные данные. Если это подключение с тех пор было отключено или переавторизовано, восстановленная версия подхватит текущее состояние.

Расписания, подписки на вебхуки и история запусков также остаются за пределами снапшота версии.

История версий и откат

Предыдущие версии можно посмотреть в дропдауне версий на тулбаре холста. При выборе старой версии она загружается на холст в режиме read-only-превью, а вверху появляется баннер: «Восстановить эту версию». Клик по кнопке вызывает tRPC-мутацию workflow.restoreVersion, которая копирует определение выбранной версии в новый черновик. Дальше вы разворачиваете его как любое другое изменение — восстановленный черновик проходит ту же валидацию и становится новейшей развёрнутой версией.

Есть ещё эндпоинт workflow.revert, используемый для некоторых AI-сценариев, и workflow.archiveVersion для хозяйственных нужд. Большинство пользователей ходят через restore.

Откаты не удаляют историю. Старая развёрнутая версия остаётся в таблице как archived и видна в дропдауне.

Остановка и деактивация

Когда event-driven workflow находится в active_waiting или active_running, главная кнопка тулбара холста — Остановить. Клик вызывает tRPC-эндпоинт workflow.pause: статус переводится в stopped, а deactivateWebhooks() вызывает onDisable у каждого триггера, удаляет polling-задачи и помечает подписки неактивными.

После остановки триггер больше не слушает. Входящие webhook-события для остановленного workflow отбрасываются webhook-роутером — они не ставятся в очередь для последующего повтора. Плановые триггеры, пока остановлены, просто не срабатывают.

Чтобы перезапустить, нажмите Запустить — та же главная кнопка снова становится доступной, как только статус stopped (или error). Triggo заново зарегистрирует внешний вебхук или пересоздаст polling-задачу, прежде чем вернуть статус в active_waiting.

Авто-остановка при повторных сбоях

Triggo сам остановит workflow, если тот упадёт три раза подряд. Когда это происходит, статус переходит в stopped (отслеживается через Redis-ключ autopause:{workflowId}:failures), а в списке workflow вы увидите его с контекстом ошибки. Полная механика авто-паузы и восстановления описана в разделе обработка ошибок.

Смотрите также

• Обзор конструктора workflow
• Обработка ошибок
• Публикация workflow как действий