Концепция распределённого исполнения

Чтобы уверенно строить процессы, важно понимать, как они выполняются «под капотом»: где живёт состояние, как шаги попадают к исполнителям и что происходит при сбое.

На какие вопросы отвечает раздел: Как процесс реально исполняется? Где состояние? Что будет при падении узла? Почему долгие процессы нормальны?

Модель исполнения

Процесс — это граф узлов. Когда вы его запускаете, платформа строит снимок и ведёт Запуск шаг за шагом. Оркестратор читает из БД, какие узлы уже можно выполнить, и назначает их исполнителям. Ответ исполнителя платформа записывает в БД. После этого готовы зависящие узлы.

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

Stateless-шаги

Исполнитель не хранит контекст между вызовами: входные данные шага приходят во входном payload. Общее состояние между узлами вы передаёте явно через payload и хранилища (файлы, секреты, БД).

Статусы узлов и результаты выполнения шагов живут в БД. Запуск остаётся в статусе выполнения, пока не завершён или не отменён, даже если отдельные шаги ждут внешнего события или подтверждения человека.

Восстановление и масштабирование

Состояние Запуска и статусы узлов хранятся в БД. При сбое исполнителя оркестратор снова назначает узел, для которого ещё нет терминального результата выполнения шага. Запуск продолжается из записанного состояния, без перезапуска всего графа.

Встроенные исполнители масштабируются горизонтально: очередь задач распределяет шаги между репликами.

Когда терминальный результат выполнения шага уже записан, платформа принимает только эту запись. Повторные и запоздалые ответы исполнителя по тому же узлу не меняют зафиксированный статус. Так платформа согласует результат при гонках и двойной доставке сообщений.

Что это значит для вас

Платформа может назначить шаг снова, пока результат выполнения шага ещё не зафиксирован, например после падения исполнителя. Спроектируйте логику узла так, чтобы повторное исполнение на вашей стороне оставляло данные согласованными. Передавайте контекст между узлами явно через payload и хранилища. Длинные цепочки, ожидания и паузы штатны: Запуск может идти часами и днями, пока платформа держит Состояние Запуска в БД.

Дальше

• Процессы: как это выглядит в редакторе.
• Подтверждения шагов: шаги с участием человека.
• Архитектура: устройство ядра целиком.