Порядок выполнения и Merge: почему ветки выполняются не так, как ты думаешь

Когда ты строишь в n8n workflow, который после узла If или Switch разделяется на несколько веток, ты, вероятно, предполагаешь, что эти ветки выполняются одновременно и просто снова встречаются на узле Merge. Именно это предположение регулярно вызывает путаницу, ведь n8n выполняет ветки не параллельно в смысле одновременно, а в фиксированном, прослеживаемом порядке. Кто не знает этот порядок, удивляется выполнениям, которые как будто происходят в неправильной последовательности, вызовам API, которые обгоняют друг друга, или узлу Merge, который, кажется, вечно висит.

Хорошая новость: логика этого четко задокументирована и надежно предсказуема с помощью нескольких базовых правил. В этой статье мы рассмотрим, как n8n определяет порядок выполнения, что изменилось с версией 1.0 и чего на самом деле ждет узел Merge, если ты однажды разберешься в его логике. Так ты сохраняешь контроль над своими workflow, даже если они становятся сложнее с каждой дополнительной веткой.

Две логики выполнения: v0 (legacy) и v1.0+

Согласно официальной документации по Execution Order, n8n различает два принципиально разных режима выполнения в зависимости от того, когда был создан workflow:

• v0 (legacy): В workflow, созданных до версии 1.0, по умолчанию действует старая логика. При этом n8n сначала выполняет первый узел каждой ветки, затем второй узел каждой ветки и так далее. Таким образом, ветки выполняются слой за слоем параллельно друг другу, а не полностью одна за другой.
• v1.0 и новее: Начиная с версии 1.0, n8n полностью обрабатывает одну ветку, прежде чем начать следующую. Таким образом, ветка выполняется полностью, включая все содержащиеся в ней узлы, прежде чем n8n переходит к следующей ветке.

Это различие лежит в основе большинства недопониманий. Тот, кто работает со старым workflow или использует шаблон из старого туториала, сталкивается с другим поведением, чем тот, кто строит только что созданный workflow в актуальной версии n8n. Согласно документации, оба режима можно настроить через настройки workflow, если тебе целенаправленно нужно другое поведение.

Как n8n определяет порядок веток

Для workflow начиная с версии 1.0 действует фиксированное, прослеживаемое правило: n8n ориентируется на позицию узлов на холсте. Ветки обрабатываются сверху вниз. Если две ветки находятся на одной высоте, решает горизонтальная позиция, при этом левая ветка выполняется первой.

На практике это означает: если ты располагаешь в своем workflow две или три параллельные ветки после узла Switch, только визуальное расположение на холсте определяет, какая ветка идет первой, а не порядок, в котором ты провел соединения, и не какой-либо внутренний ID. Это особенно важно, когда отдельные ветки имеют побочные эффекты, например, запись в одну и ту же таблицу, обновления одной и той же записи CRM или вызовы одного и того же API с ограничением скорости. Если одна ветка выполняется раньше другой, результат второй ветки может зависеть от первой, даже если это не было задумано в дизайне workflow.

Узел Merge: чего он на самом деле ждет

Узел Merge объединяет данные из нескольких источников в один поток. В режиме Append действует простое, но часто упускаемое из виду правило: узел ждет, пока все подключенные входы не будут выполнены, прежде чем продолжить работу сам. Только когда каждый вход предоставил данные или явно не предоставил никаких данных, узел Merge выдает результат.

Это объясняет два частых наблюдения из практики:

• Узел Merge, который кажется зависшим, на самом деле обычно ждет ветку, которая еще не завершена или никогда не выполняется из-за условия.
• При неравной длине потоков данных действует правило: элементы, поступающие на вход 1, имеют приоритет. Если узел Merge получает, например, пять элементов на входе 1 и десять элементов на входе 2, он обрабатывает только пять элементов, потому что вход 1 задает верхний предел.

После крупной переработки узла Merge в версии 0.194.0 и расширения до более чем двух входов, а также добавления режима SQL-запросов в версии 1.49.0, теперь также можно одновременно объединять более двух веток, что значительно упрощает классическую логику двух веток в более крупных workflow. Подробности обо всех режимах объединения, таких как Append, Combine и Choose Branch, можно найти в руководстве по объединению потоков данных.

Ловушка в старых workflow: узел If плюс Merge

Особенно коварное поведение, согласно документации, касается исключительно workflow с устаревшим порядком выполнения v0, то есть по умолчанию всех workflow, созданных до версии 1.0. Если ты добавишь узел Merge к структуре, содержащей узел If, в таком workflow может случиться, что выполнятся оба выходных потока узла If, хотя узел If на самом деле должен был запускать только один из двух путей. Причина: один поток данных запускает узел Merge, который затем выполняет также другой, фактически неактивный поток данных.

Это поведение было устранено в версии 1.0. Тот, кто мигрирует или поддерживает старый workflow и наблюдает необъяснимые дублирующиеся выполнения после узла If, часто находит здесь причину. Переключение на новый порядок выполнения в настройках workflow обычно надежно решает проблему.

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

Прежде чем отлаживать существующий workflow, стоит бегло взглянуть на настройки workflow: там видно, какой порядок выполнения активен в данный момент, и при необходимости можно переключиться между v0 и v1.0. Для новых workflow, как правило, рекомендуется актуальная логика, потому что она более предсказуема, и описанная ловушка If-плюс-Merge вообще не возникает.

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

Часто задаваемые вопросы

Действительно ли ветки в n8n не выполняются параллельно?

Нет, по крайней мере не в смысле одновременного выполнения. В workflow начиная с версии 1.0 n8n полностью обрабатывает одну ветку, прежде чем начать следующую, что управляется позицией узлов на холсте. В более старых workflow версии v0 выполнение вместо этого происходит узел за узлом, слой за слоем по всем веткам, что также не является настоящим параллелизмом.

Почему мой узел Merge, кажется, ждет бесконечно?

В режиме Append узел Merge ждет выполнения всех подключенных входов. Если одна из предыдущих веток не завершается, например, потому что условие не выполнено или узел выдает ошибку, узел Merge никогда не получает сигнал от этого входа и, соответственно, не дает результата.

Что происходит, если два входа узла Merge предоставляют разное количество элементов?

Элементы на входе 1 имеют приоритет. Если узел Merge получает, например, пять элементов на входе 1 и десять на входе 2, он обрабатывает только пять элементов, потому что вход 1 задает верхний предел для обработки.

Затрагивает ли ловушка If-плюс-Merge также новые workflow?

Нет. Согласно документации n8n, это поведение касается исключительно workflow с устаревшим порядком выполнения v0, то есть по умолчанию всех workflow, созданных до версии 1.0. В недавно созданных workflow с актуальным порядком выполнения эта проблема больше не возникает.

Могу ли я впоследствии изменить порядок выполнения для существующего workflow?

Да. Порядок выполнения можно изменить в настройках workflow. Это особенно полезно для старых, мигрированных workflow, если ты наблюдаешь необъяснимые многократные выполнения после узлов If или Switch и подозреваешь, что причина кроется в устаревшей логике v0.