Углублённая модель данных n8n

Merge и потеря связей между items

Содержание курса

Исправление через Merge по request_id и проверка ancestry

Диагностика из предыдущего шага использовала временно переименованные поля (request_id_input1 / request_id_input2) — они нужны только чтобы увидеть оба значения рядом в output Merge. Перед исправлением уберите эти Edit Fields-ноды из workflow: поле request_id должно снова приходить на оба входа Merge под исходным именем. Только тогда режим Matching Fields сможет сопоставлять записи по одному и тому же ключу.

Переключите Merge в режим Mode: Combine → Combine By: Matching Fields и укажите Fields to Match = request_id. Теперь нода ищет совпадения по значению поля, а не по порядку в массиве: для каждого item из входа 1 она находит ровно один item из входа 2 с тем же request_id.

По умолчанию Output Type выставлен в Keep Matches — в output попадают только те пары, где request_id совпал на обоих входах. Поскольку request_id уникален на каждом входе и все три значения присутствуют в обеих ветках, результат детерминирован:

Output-item request_id (вход 1) request_id (вход 2) Совпадают?
0 R-101 R-101 ✓
1 R-102 R-102 ✓
2 R-103 R-103 ✓

Порядок во втором входе больше не имеет значения — Merge сам строит правильные пары.

После переключения первое, что нужно проверить, — количество output-items. Их должно быть ровно три. Если поле потеряно или переименовано в одной из веток, совпадений не будет и Keep Matches вернёт пустой массив. Если нужно сохранить items без пары, выберите Output Type = Keep Everything или Keep Non-Matches; для обогащения данных первого входа без отбрасывания несовпавших строк подойдёт Enrich Input 1.

Теперь верифицируйте, что паросочетание исправлено и downstream-выражение работает. Сделайте это в три шага.

Шаг 1. Убедитесь, что исходный request_id присутствует на обоих входах. Откройте execution data нод обеих веток непосредственно перед Merge и проверьте, что поле называется request_id (не request_id_input1/request_id_input2) и присутствует во всех items. Это предусловие: без него Matching Fields не найдёт ни одного совпадения.

Шаг 2. Проверьте output-items в панели Output Merge. Откройте вкладку Output ноды Merge и для каждого из трёх items убедитесь, что поле request_id имеет ожидаемое значение. Для этой проверки не требуется включать Clash Handling с добавлением номера входа к имени поля: достаточно проверить итоговый request_id и количество строк. Три совпавших строки подтверждают, что Merge построил верные пары.

Шаг 3. Убедитесь, что downstream-выражение разрешается без ошибки. Добавьте после Merge тестовую ноду (например, Set или Edit Fields) и введите в любом поле выражение {{ $('Source Requests').item.json.request_id }}. Запустите workflow. Если для каждого из трёх output-items выражение возвращает тот же request_id, что и в самом item, — цепочка pairedItem однозначна и выражение .item работает корректно. Если Keep Matches возвращает пустой output, проверьте наличие и имя поля сопоставления, а также значения на обоих входах.

Если output-items есть, но выражение бросает ошибку Multiple matching items for expression, проверьте их ancestry: для текущего output-item существует больше одного кандидата из Source Requests.

Когда все три шага дают ожидаемый результат, downstream-выражение работает корректно для каждой из трёх записей fixture.

Начать заново?

Помощник начнёт новый диалог по этой задаче. Текущая переписка останется в истории до конца срока хранения.

О переписке

Можно приложить до трёх фото PNG, JPEG или WebP по 5 МБ.

Переписка и фото хранятся 90 дней после последнего принятого сообщения. Преподаватель получит доступ к диалогу, когда вы попросите его помочь.

Проверка решения остаётся отдельным действием.