Merge node теряет items в n8n ¶

Обновлено: 2026-05-29

Потеря items после Merge отличается от дублей: часть входных записей не попадает в output, потому что режим Merge оставляет только совпавшие пары, ключ пустой или нестабильный, порядок items не совпадает, а unmatched records не отправляются в отдельную ветку. Диагностика должна показать, какие именно записи исчезли и по какому правилу.

Когда открывать эту страницу ¶

• после Merge количество items меньше, чем ожидалось
• исчезают только записи без пары во втором потоке
• часть лидов/заказов не доходит до CRM, но workflow не падает
• ручной тест на одном совпавшем item проходит, а batch с unmatched ломает отчётность

Симптомы ¶

• после ноды пропадают поля или меняется количество items
• expression иногда даёт undefined
• ручной тест на одном item проходит, production batch ломается

Вероятные причины ¶

• выбран режим, который сохраняет только совпавшие пары, хотя нужны все записи из первого потока
• ключи имеют разные типы или разные форматы: пробелы, регистр, префиксы
• unmatched items молча исчезают, потому что нет ветки rejected или лога
• после Merge downstream expression обращается к paired item, которого нет для unmatched записи

Решение по шагам ¶

1. Выгрузите ключи входа A, входа B и выхода Merge в короткую debug-таблицу.
2. Проверьте типы ключей: строка 123 и число 123 могут сравниваться иначе, чем ожидается.
3. Нормализуйте ключ до одного поля и обрабатывайте empty/null отдельно до Merge.
4. Выберите режим, который явно сохраняет нужные unmatched records, если бизнес-процесс этого требует.
5. Записывайте lost/unmatched items в отдельную ветку с причиной: missing_pair, empty_key, type_mismatch.

Проверка после исправления ¶

• Прогоните batch с полным совпадением, missing pair, пустым ключом и разными типами ключа.
• Сравните set ключей до и после Merge, а не только общее количество items.
• Убедитесь, что unmatched records попадают в отдельную ветку или отчёт.
• Проверьте, что downstream не падает на отсутствующих paired items.

Профилактика ¶

• добавьте Error Trigger или отдельную error branch
• логируйте execution id, внешний id и краткую причину ошибки
• не отправляйте секреты в логи, Telegram, Slack или AI prompt
• для production настройте alert только на actionable события

Глубокая диагностика: что проверить до изменения workflow ¶

Для проблемы Merge node теряет items в n8n сначала зафиксируйте факты, а не меняйте ноды наугад. Откройте failed execution, найдите первую ноду, где входные данные ещё корректны, а выход уже отличается от ожидаемого. Сравните не только текст ошибки, но и item count, полный JSON, headers, status code, binary data и время выполнения.

• Запишите слой сбоя: данные, авторизация, API, нода, очередь, база, reverse proxy или AI-слой.
• Соберите минимальный воспроизводимый пример на одном item и отдельно прогоните batch из 3–5 items.
• Проверьте, не маскирует ли retry исходную ошибку: в истории executions смотрите первый, а не последний сбой.
• Если задействован внешний сервис, данные и execution history, сравните реальный request/response из n8n с рабочим запросом вне n8n, скрыв секреты.
• После исправления сохраните пример плохого payload в тестовом workflow или в runbook, чтобы не терять контекст.

Решение без побочных эффектов ¶

Правка должна быть минимальной: исправляйте только тот слой, где доказана причина. Для Merge node теряет items в n8n опасно одновременно менять credentials, mapping, retry и бизнес-логику: после этого сложно понять, что действительно помогло.

Контрольный список после исправления ¶

• один успешный и один проблемный пример проходят предсказуемо
• в execution видно, какие данные ушли дальше по цепочке
• ошибка больше не скрывается за общим сообщением вроде “workflow failed”
• alert отправляется владельцу workflow с ID execution и короткой причиной
• для внешних записей есть ключ идемпотентности: order_id, event_id, email+date или payload_hash

Связанные материалы ¶

• Решения проблем n8n
• Ошибки n8n
• Executions

Практический минимум перед закрытием задачи ¶

• откройте последнюю failed execution и сравните input/output проблемной ноды
• повторите сценарий на одном item с минимальным payload
• проверьте успешный, пустой и ошибочный вход
• после исправления запустите тот же event_id повторно и убедитесь, что нет дублей

Шаблон записи в runbook ¶

В комментарии к workflow полезно оставить короткую запись: симптом, корневая причина, изменённая нода, внешний id тестового события и критерий успешной проверки. Это превращает разовое исправление в reusable runbook для команды.

Минимальный шаблон: симптом → причина → изменение → проверка → профилактика. Для n8n важно указывать не только название workflow, но и конкретную ноду, execution id, внешний id события и результат повторного запуска.

Когда не стоит усложнять workflow ¶

Не добавляйте AI, очередь, отдельную базу или сложный Code node, если проблема решается явной валидацией поля, простым IF/Switch, правильным credential или корректным retry. Чем меньше скрытой магии, тем легче поддерживать workflow через месяц.

Диагностика по шагам: как не лечить симптом вслепую ¶

Проблему Merge node теряет items в n8n лучше разбирать как incident, а не как случайную ошибку в одной ноде. Сначала соберите доказательства, затем меняйте настройки workflow.

Проверка за 7 минут ¶

1. Откройте последний failed execution и сравните его с последним successful execution того же workflow.
2. Зафиксируйте входной item: сколько items пришло, какие поля отсутствуют, есть ли binary data.
3. Проверьте credentials отдельно: токен, scopes, refresh, базовый URL, права пользователя.
4. Повторите запрос из HTTP Request через curl/Postman с теми же headers и body.
5. Посмотрите, не сработали ли rate limits, timeout, proxy, SSL или блокировка по IP.
6. Если ошибка плавающая, добавьте временный лог в безопасное хранилище: execution_id, event_id, status_code, краткое тело ответа.

Правильный порядок исправления ¶

После фикса ¶

• запустите старый failed payload повторно на тестовой копии workflow;
• проверьте, что ошибка не превратилась в silent failure;
• добавьте ссылку на эту страницу в error workflow или alert-сообщение;
• для повторяющихся инцидентов используйте workflow уведомлений об ошибках.