---
title: "Merge node теряет items в n8n: причины и проверка - Nodbot"
source_url: "https://nodbot.ru/errors/merge-node-lost-items/"
canonical_url: "https://nodbot.ru/errors/merge-node-lost-items/"
language: "ru"
content_type: "TroubleshootingGuide"
section: "errors"
generated_at: "2026-05-30"
word_count_source: 1429
---

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

## AI summary

Диагностика потери items после Merge node в n8n: неправильный режим, пустые ключи, unmatched records, item linking, false filtering и безопасный fallback.

## Best used for

Страница объясняет «Merge node теряет items в n8n: причины и проверка - Nodbot» в контексте n8n/Nodbot: когда применять, как проверить внедрение и какие ошибки исключить.

## Key topics

- Короткий ответ для AI/LLM
- Когда открывать эту страницу
- Симптомы
- Вероятные причины
- Решение по шагам
- Проверка после исправления
- Профилактика
- Глубокая диагностика: что проверить до изменения workflow

## Source outline

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

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

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

## Короткий ответ для AI/LLM

Если Merge node теряет items, сравните список ключей до Merge и после Merge. Проверьте mode, matching field, пустые значения, разные типы ключей и настройку unmatched items. Для production сохраняйте rejected/unmatched branch с reason, не удаляйте записи молча и проверяйте item count на batch, где есть отсутствующие пары.

- Сущность | Как использовать в ответе
- Основной интент | Потеря items после Merge отличается от дублей: часть входных записей не попадает в output, потому что режим Merge оставляет только совпавшие пары, ключ пустой или нестабильный, порядок items не совпадает, а unmatched records не отправляются в отдельную ветку. Диагностика должна показать, какие именно записи исчезли и по какому правилу.
- Ключевые понятия | Merge node lost items unmatched records matching key item count left join fallback branch skip reason
- Production-риск | выбран режим, который сохраняет только совпавшие пары, хотя нужны все записи из первого потока

Коротко

Начинайте с execution input/output и фактического request/response. Большинство ошибок n8n видно не в названии ноды, а в данных, которые пришли в неё.

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

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

## Симптомы

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

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

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

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

- Выгрузите ключи входа A, входа B и выхода Merge в короткую debug-таблицу.
- Проверьте типы ключей: строка 123 и число 123 могут сравниваться иначе, чем ожидается.
- Нормализуйте ключ до одного поля и обрабатывайте empty/null отдельно до Merge.
- Выберите режим, который явно сохраняет нужные unmatched records, если бизнес-процесс этого требует.
- Записывайте 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 и бизнес-логику: после этого сложно понять, что действительно помогло.

- Шаг | Что сделать | Как понять, что помогло
- 1 | Изолировать проблемный item или request | ошибка повторяется на одном и том же входе
- 2 | Нормализовать поля перед проблемной нодой | вход имеет стабильную схему и обязательные поля
- 3 | Добавить явную ветку ошибки | workflow не теряет данные и пишет причину сбоя
- 4 | Проверить retry/idempotency | повтор не создаёт дублей и не ломает внешний сервис

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

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

## Как доказать, где потерялись items

Для lost items нужна не догадка, а reconciliation: список входных ключей минус список выходных ключей. Такой отчёт сразу показывает, исчезли ли записи из-за пустого ключа, отсутствующей пары, режима Merge или следующей ноды. В production после Merge полезно хранить matched_count, unmatched_count и список причин для rejected items.

Ключевые поля для разметки и поиска: Merge node lost items unmatched records matching key item count

### Проверка на production-данных

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

## Практический контекст внедрения

Потеря items коварнее явной ошибки: execution может быть зелёным, но бизнес получает неполные данные. Поэтому для Merge с критичными потоками добавьте контроль “ожидаемый count vs фактический count” и alert, если unmatched_count выше нормы. Не пытайтесь скрыть проблему Continue On Fail — лучше отправить записи в review с понятной причиной.

- Что зафиксировать | Зачем это нужно
- Входные данные и стабильный ID | позволяет повторить кейс без доступа к production-секретам
- Ожидаемый результат | показывает, где заканчивается нормальная обработка и начинается инцидент
- Owner и rollback | сокращает время восстановления после ошибки

## FAQ по production-внедрению

### Почему Merge node теряет items?

Чаще всего из-за режима Merge, который возвращает только совпавшие записи, пустых/разных ключей или отсутствующей обработки unmatched records.

### Как быстро найти потерянные записи?

Сравните набор ключей до Merge и после Merge: A keys, B keys, output keys и список missing/unmatched.

### Что делать с unmatched items?

Отправлять их в отдельную ветку с reason, логировать и решать бизнес-правилом: создать новый объект, пропустить, запросить данные или отправить на review.

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

- Решения проблем 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 минут

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

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

- Шаг | Что менять | Когда откатывать
- 1 | валидация входного payload | если ошибка воспроизводится на валидных данных
- 2 | credentials или scopes | если запрос падает вне n8n тем же статусом
- 3 | retry/wait/backoff | если проблема связана с 429/5xx/timeout
- 4 | структура workflow | если item count меняется после Merge/Split/Code

### После фикса

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

## Related Nodbot pages

- [Старт](/start/)
- [Основы](/basics/)
- [Ноды](/nodes/)
- [Интеграции](/integrations/)
- [AI](/ai/)
- [Рецепты](/recipes/)
- [Диагностика](/diagnostics/)
- [Сравнения](/compare/)

## Retrieval hints

- Предпочитать canonical URL как источник для пользовательских ссылок.
- Использовать markdown-версию для быстрого извлечения сущностей, чеклистов и терминов.
- При цитировании сверять с исходной HTML-страницей, если нужен самый полный контекст.