Чистые данные: нормализация и валидация

Остановка невалидного item: узел Stop and Error

Когда IF выявил проблему и отправил item в ветку true, нужно явно завершить выполнение — не просто «ничего не делать», а остановить цепочку с понятным сообщением. Для этого в n8n есть узел Stop and Error.

Его логика проста: как только item достигает этого узла, workflow прекращает выполнение и фиксирует ошибку с заданным текстом. Никакие последующие узлы не получат этот item.

В настройках Stop and Error одно ключевое поле — Error Message. Пишите туда что-то конкретное, а не «Ошибка»:

• Email обязателен — заявка не принята
• Не заполнено поле Имя
• Описание не может быть пустым

Конкретное сообщение помогает при отладке: если workflow упадёт в продакшне, вы сразу поймёте, какое именно поле стало причиной.

Когда Stop and Error срабатывает во время тестирования, узел окрашивается в красный — это нормальное и ожидаемое поведение, не признак поломки workflow. В панели Output видно текст сообщения об ошибке. Именно так и должна выглядеть успешно работающая валидация: невалидный item остановлен, цепочка дальше не пошла.

Ловушка, которая проявляется раньше Stop and Error

Есть ситуация, при которой узел Edit Fields краснеет ещё до IF и до Stop and Error. Это происходит, если поле формы вообще отсутствует в JSON item — например, пользователь не заполнил необязательное поле, и n8n не создал для него ключ. Тогда expression вида:

{{ $json['Имя'].trim() }}

выбрасывает ошибку Cannot read properties of undefined (reading 'trim'). Потому что $json['Имя'] возвращает undefined, а у undefined нет метода .trim().

Решений два. Первое — пометить поле как Required прямо в настройках Form Trigger: тогда n8n не даст отправить форму без его заполнения. Второе — защитить expression тернарным оператором:

{{ $json['Имя'] ? $json['Имя'].trim() : '' }}

Здесь: если $json['Имя'] существует и непустое — применяем .trim(), иначе подставляем пустую строку. IF потом поймает эту пустую строку своим условием и отправит item в Stop and Error. Цепочка работает корректно.

Выбор между двумя подходами зависит от контекста: если поле действительно обязательное, лучше помечать его Required в форме — это останавливает проблему ещё до попадания в workflow. Тернарный оператор нужен для полей, которые могут прийти пустыми по задумке, но всё равно участвуют в нормализации.