Отладка на безопасных данных

Workflow может закончиться без технической ошибки и всё же не выполнить свою задачу. Например, P-003 исчезнет, если Switch не выдаёт запасной выход. Две остальные заявки подготовятся корректно, поэтому схема будет выглядеть убедительно. Разберём этот случай через промежуточные данные и составим безопасный набор для отладки.

История настоящего n8n в уроке не использовалась. Файл diagnostic-cases.json содержит собственные ожидаемые и намеренно неправильные состояния, а не журнал выполнений. Мы не повторяем запросы и не запускаем подготовку. Цель — научиться выбирать место сравнения и объяснять, почему исправление решает конкретный дефект.

Собственные файлы этого шага доступны в архиве fixtures и контрактов серии, папка lesson-08. Это приложения к объяснению, а не готовый экспорт workflow.

Сначала определить правильный результат

Для трёх предложений должны существовать три исхода: web-очередь для P-001, SEO-очередь для P-002, ручная проверка для P-003. Одобрение остаётся ложным. Это описание результата сильнее утверждения «все узлы зелёные»: оно относится к задаче редакции. Технический статус говорит о выполнении операций, но не знает, насколько полно мы описали нужное поведение.

Введём ошибочную конфигурацию Switch: правила web и SEO есть, а fallback равен None. Значение web3 ни одному правилу не соответствует. Ожидается, что оно не попадёт в дальнейшую подготовку. Процесс может не получить исключения, потому что такое поведение допускается настройкой узла. Следовательно, отсутствие ошибки исполнения не является подтверждением сохранности предложений.

Не нужно искать проблему сразу в Aggregate или менять заголовок P-003. Сначала сравним набор идентификаторов перед и после маршрутизации. До неё должны быть все три, после неправильного Switch останутся два. Мы нашли первую границу, на которой нарушается договор. Остальные преобразования могут быть исправными и лишь показывать уже неполный вход.

Контрольная точка	Ожидаемые идентификаторы	Ошибочный вариант	Вывод
Исходный образец	P-001, P-002, P-003	Все три	Приём описан верно
Нормализация	Все три	Все три	Поля не теряют item
Маршрутизация	Все три исхода	Только первые два	Проверить fallback
Подборка	Три карточки	Две карточки	Последствие ранней потери

Сравнение по идентификаторам позволяет обнаружить и другую проблему: три выходные строки могут содержать P-001 дважды и не содержать P-003. Одно равенство чисел недостаточно. Для нашей задачи важны состав набора и один объяснимый исход каждого предложения. В настоящем хранилище контроль дубликатов потребовал бы отдельного устойчивого механизма, который здесь не реализован.

Архивный интерфейс: выражение с отсутствующим полем приводит к ошибке в узле. Изображение показывает учебную запись 2024 года, а не результат нашего fixture. В ней выражение обращается к body.id; наш внутренний редакционный объект после адаптации использует другое расположение полей. Разница помогает понять, почему выражение нужно сопоставлять с фактическим JSON, а не копировать по внешнему виду панели.

Закреплённые данные для одного вопроса

Data pinning сохраняет выход узла для повторного использования при разработке. Это удобно, когда нужен один и тот же вход без новых обращений к внешнему источнику. Закреплённые данные не используются производственными выполнениями. Документация pinning также описывает создание и редактирование учебных данных; это средства разработки, а не накопитель событий.

Для нашего случая нужен образец всех трёх нормализованных заявок. Если закрепить только P-001, исправный маршрут web ничего не скажет о fallback. Если закрепить уже готовую правильную подборку, мы вообще обойдём проблемный узел. Выбор точки должен соответствовать вопросу: хотим проверить маршрутизацию, значит её вход должен содержать известные и неизвестную темы.

Изменение закреплённого вывода не исправляет исходное событие. Оно создаёт другой образец для будущего ручного рассмотрения. Поэтому храните описание происхождения: синтетический fixture, обезличенные данные прежнего выполнения или вручную изменённый вариант. Смешав их без отметки, можно принять придуманное состояние за фактический результат системы и неправильно объяснить причину ошибки.

В нашем наборе не содержатся реальные запросы, токены и сведения посетителей. Флаги data_pinned и history_loaded ложные: никакие данные не загружались в редактор. Приведённый образец показывает, что следует подготовить для соответствующей операции, если вы позднее самостоятельно исследуете workflow в подходящем локальном окружении.

Debug in editor и Copy to editor

Если нужное выполнение сохранено, n8n позволяет загрузить его данные в текущий workflow. Для неуспешного случая используется Debug in editor, для успешного — Copy to editor. Данные закрепляются в первом узле. Доступность зависит от варианта установки и регистрации. Руководство отладки выполнений описывает процедуру и условия функции.

Наш дефект как раз может потребовать Copy to editor: техническое выполнение могло считаться успешным. Однако копирование само по себе не добавляет третью карточку. Нужно прочитать вход, обнаружить неизвестную тему и изменить правило fallback. После этого ожидаемый результат снова должен включать P-003 с причиной unknown_topic, а не переименованную под известное направление заявку.

Не переносите необезличенную историю в публичный пример или сообщение в сообществе. Для объяснения потери достаточно идентификаторов, кодов тем и структуры узлов. Подлинные тексты предложений и авторизационные заголовки не помогут понять правило Switch. Минимальный образец одновременно упрощает разбор и уменьшает ненужное раскрытие данных.

Для точного разбора fallback возьмите подготовленную цепочку урока 5 и убедитесь, что Fixture proposals содержит все три записи. У Topic route временный неправильный вариант описывается значением Fallback Output: None; исправленный вариант — Extra Output с проводом к Edit Fields ручной очереди. В этой ветке задаются queue и reason, перечисленные в уроке 5. Для сравнения входов при самостоятельном исследовании откройте Normalize proposals в JSON-представлении, затем каждый выход Topic route: P-003 должен сохраняться только в ручном выходе, а не попадать в web или SEO.

Повтор исполнения и исправленный вход

В истории неуспешных выполнений n8n различает повтор с текущим сохранённым workflow и повтор с исходной версией. Описание списка Executions поясняет варианты. Повтор исходной версии не применит новое правило fallback, а повтор сохранённой версии не является автоматически публикацией этого правила в production.

При выборе повтора нужно знать, какие промежуточные данные используются и какие действия могли уже произойти. Не следует обещать, что исправление раннего узла будет непременно заново применено ко всему потоку конкретного повторного исполнения. Если требуется пересчитать входные преобразования, отдельное рассмотрение в редакторе даёт более понятный контроль. Наши состояния не подтверждают поведение retry в установленном экземпляре.

Если процесс позже создаёт внешние задачи, повтор способен создать дубликаты. До его выполнения нужно сопоставить уже принятые действия с идентификатором предложения и политикой получателя. Сейчас внешние действия отсутствуют, а retry_performed ложное. Мы обсуждаем механизм выбора, не подменяя его обещанием однократной доставки или фактически восстановленной очереди.

Исправление и соседние случаи

Предметное исправление — включить дополнительный fallback и сформировать manual_review. После этого рассмотрите соседние fixtures: пробельный заголовок P-001 и числовая тема P-002. Первый должен дать title_empty, второй — topic_string_required; оба должны оказаться в проверке входа. Новая ветка неизвестной темы не должна превращать эти ошибки формы в пригодные предложения.

После самостоятельного ручного запуска исправленного учебного варианта ожидается наличие P-003 на выходе Manual review. Сначала сравните этот результат, затем отдельно рассмотрите два случая неправильной формы. Не ограничивайтесь пересчётом двух известных тем: именно неизвестная тема раскрывала исходный дефект. Если результат отличается, начните с первой контрольной точки таблицы и найдите, где состав идентификаторов изменился.

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