Отладка запусков
Изучение запуска pipeline — события журнала, входы и выходы шагов, повтор (replay).
Отладка запусков
Когда workflow ведёт себя не так, Triggo даёт одно место, чтобы разобраться почему: детальное представление запуска. Каждый выполненный шаг, каждый полученный вход, каждый возвращённый байт, каждая брошенная ошибка — всё это есть в журнале. Эта страница рассказывает, как найти запуск, как читать журнал, что редактируется, какие классы ошибок встречаются чаще всего и как работает replay.
Как найти запуск
Вкладка Runs показывает все выполнения в вашем рабочем пространстве, новые сверху. Каждая карточка содержит slug действия, бейдж статуса, источник (например, webhook, schedule, manual, replay), длительность и timestamp. Кликните по строке, чтобы открыть детали.
Над списком — три фильтра:
- Action slug — свободный текстовый поиск по действию.
- Status — один из
accepted,running,waiting_for_approval,succeeded,failed,cancelled,timed_out. - Source — один из
action,webhook,schedule,manual,replay,test,dry_run.
Результаты разбиваются по 20 на страницу. Поиска по correlation ID в UI пока нет — если у вас есть correlation ID от внешнего агента, используйте runtime API (GET /api/v1/runtime/runs).
Журнал — что означает каждое событие
Каждое выполнение шага пишет одно или несколько событий в таблицу execution_events. Детальное представление показывает их по порядку. Типов событий ровно семь. Разберитесь в них — и сможете прочитать любой запуск.
| Событие | Значение | Когда срабатывает |
|---|---|---|
step_started | Шаг начал выполнение. Несёт разрешённый inputData. | Записывается прямо перед вызовом обработчика коннектора/кода/LLM. |
step_completed | Шаг завершился успешно. Несёт outputData и durationMs. | Записывается после возврата обработчика без исключения. |
step_failed | Шаг бросил ошибку или вернул сбой, и запуск остановится. | Записывается, когда обработчик падает и у шага не установлен continueOnFailure. |
step_failed_continued | Шаг упал, но запуск продолжается. | Тот же триггер, что и step_failed, но только когда у шага установлен флаг continueOnFailure. См. Обработка ошибок. |
step_skipped | Шаг не выполнился, потому что путь DAG, ведущий к нему, не был выбран. | Записывается, когда ветвь условия даёт false или условный предшественник обошёл этот узел. |
step_timed_out | Шаг превысил таймаут шага 30 с. | Записывается планировщиком шагов, когда срабатывает сторожевой таймер шага. В payload ошибки code: "TIMEOUT". |
step_pending_approval | Запуск ждёт решения человека. | Записывается, когда достигнут approval gate; статус переходит в waiting_for_approval, выполнение приостанавливается. |
Одна тонкость, которую стоит выделить: для resume/replay исполнитель трактует step_completed, step_skipped и step_failed_continued как «этот узел готов, не перезапускать». Именно поэтому повторный запуск может подхватить после частичного сбоя без двойного срабатывания побочных эффектов.
Осмотр входов и выходов шага
Детальное представление запуска показывает полезные нагрузки каждого шага в двух панелях:
- Input —
inputDataиз событияstep_started. Что шаг реально увидел после сопоставления полей, приведения типов и подстановки данных триггера. - Output —
outputDataизstep_completed(или payloaderrorизstep_failed/step_timed_out).
Если нижестоящий шаг получил нечто неожиданное, смотрите именно сюда. Сопоставьте выражения из конфига шага с тем, что пришло в inputData. Неопределённые ссылки обычно указывают на опечатку в пути {{node.field}} или на то, что предшественник записал не ту форму, которую вы ожидали.
Редакция
Все полезные нагрузки пропускаются через sanitize() в до сохранения. Рекурсивно, с ограничением глубины 10. Он переписывает строковые значения, подпадающие под любой из этих паттернов:
- OAuth bearer-токены →
Bearer [REDACTED] - Присваивания
api_key=...,access_token=...,secret_key=...со значениями от 16 символов →[REDACTED] - Email-адреса →
[REDACTED_EMAIL] - Телефоны российского формата (
+7/8) →[REDACTED_PHONE] - Hex- или base64-подобные токены ≥ 40 символов →
[REDACTED_TOKEN]
Если поле, которое вам нужно отладить, отображается заредактированным, значит сработал один из этих паттернов. Числа и булевы проходят нетронутыми — редакция касается только строк.
Частые сигнатуры сбоев
Это значения code ошибок, которые вы увидите чаще всего в payload упавшего запуска. Все они определены в (CONNECTOR_ERROR_CODES) или устанавливаются исполнителем напрямую.
AUTH_EXPIRED
OAuth-токен, API-ключ или сессия коннектора больше не действительны. Refresh не помог.
Что делать. Откройте страницу Connections, переподключите интеграцию. Затем повторите упавший запуск (или дайте следующему плановому запуску подхватить). AUTH_EXPIRED не повторяется автоматически — повтор не починит мёртвые учётные данные.
RATE_LIMITED
Внешний API вернул 429 или иначе сигнализировал, что вы превысили их лимит. Если в ответе был заголовок Retry-After, исполнитель парсит его в retryAfterMs в payload ошибки.
Что делать. Это повторяемо (включено в RETRYABLE_ERROR_CODES). Если на шаге задан maxRetries, исполнитель сделает backoff и попробует снова. Иначе разнесите триггеры во времени или снизьте пропускную способность. Если по этой интеграции сработал предохранитель, вызовы будут падать быстро — так и задумано (см. Обработка ошибок).
VALIDATION_ERROR
Поле не прошло приведение типов или коннектор отверг вход. Бросается property-coercer или возвращается самим коннектором.
Что делать. Проверьте сопоставления полей шага по объявленным типам свойств коннектора. Отсутствующие обязательные поля, неверные типы (строка там, где ожидалось число), кривые enum. Сообщение message обычно называет проблемное поле.
TIMEOUT
Либо шаг превысил таймаут шага 30 с (планировщик шагов ставит code: "TIMEOUT"), либо весь pipeline превысил глобальный таймаут 300 с.
Что делать. Посмотрите на durationMs у окружающих событий, чтобы понять, какой таймаут сработал. Для одного медленного шага — сократите работу или отгрузите в очередь. Для таймаута всего pipeline — DAG слишком тяжёлый для одного запуска; разбейте его на меньшие workflow, связанные вебхуками.
UPSTREAM_ERROR
Интеграция вернула неспецифическую 5xx или другую ошибку, не отобразившуюся в коды выше. Часто временная.
Что делать. Прочтите message ошибки — там ответ внешнего API. Если временная, включение повторов (maxRetries: 2–3 с экспоненциальным backoff) обычно это переживает. Если устойчивая — это реальный сбой на их стороне; предохранитель разомкнётся после пяти сбоев за пять минут и защитит вас от молотьбы.
Ещё одна, которая может встретиться: UNKNOWN — fallback, когда исполнитель не может классифицировать ошибку (например, неожиданный throw без поля code). Это сигнал бага — что-то внутри обработчика не соответствует ожидаемой форме.
Replay
Кнопка Replay в тулбаре детального представления создаёт новый запуск из упавшего или завершённого. Исходный запуск не модифицируется.
Что делает replay:
- Клонирует
workflow_id,workflow_version_idиinputисходного запуска, затем вставляет новую строку сsource: "replay"иresume_from_run_id, указывающим на исходный. - Предзаполняет JSON-редактор исходным
input— его можно отредактировать перед подтверждением или запустить повтор с исходным входом как есть. - Ставит в очередь свежую BullMQ-задачу выполнения. Движок заново загружает текущее определение pipeline по этому
workflow_version_idи использует ваши текущие учётные данные — не снапшот с момента исходного запуска. - Возобновляет по журналу: шаги, у чьих node ID уже есть события
step_completed,step_skippedилиstep_failed_continuedв исходном запуске, не выполняются повторно. Выполнение подхватывает с упавшего узла.
Повторить можно только терминальные запуски (succeeded, failed, cancelled, timed_out). Replay running или waiting_for_approval отклоняется с BAD_REQUEST.
Кнопка replay живёт в и вызывает tRPC-мутацию run.replay, которая делегирует в executionService.replayRun в.
Смотрите также
- Обработка ошибок — повторы, continue-on-failure, предохранитель, авто-пауза.
- Лимиты — таймаут шага (30 с), таймаут pipeline (300 с), per-user лимит запусков.
- Обзор агентной интеграции — запуск и осмотр запусков от внешних агентов через runtime API.