rp-dag

Назначение

Владеет триггерами рабочих процессов и журналом выполнения. Ничего не выполняет.

Граница ответственности

Здесь находятся только две вещи и ничего больше:

Триггеры — «когда появляется эта тема шины, запустить тот рабочий процесс». Системная
конфигурация: десятки строк, которые поддерживает оператор и которые целиком хранятся
в памяти среды выполнения, а не запрашиваются.
Журнал выполнения — дерево того, что сделал запуск. Среда выполнения записывает его,
пока выполняется скрипт: узел открывается до выполнения его тела и закрывается после
завершения, поэтому выполняющийся запуск показывает узел, на котором он находится.

Каталог рабочих процессов здесь не принадлежит этому сервису. Ptah помещает дескрипторы
активного Solution в окружение этого сервиса (WORKFLOWS, WORKFLOW_DIGESTS,
MODULE_PROXY), а listAvailableWorkflows повторно публикует их для среды выполнения
и UI. Исходные байты остаются за Ptah-proxy.

Журнал записывает среда выполнения, а не этот сервис

Здесь ничего не записывает запись журнала. Среда выполнения форматирует её, помещает в Valkey
под ключом, который сама составляет, а позже передаёт ключи — никогда сами записи.
commitLog превращает каждый ключ в расположение хранилища и сообщает хранилищу, что нужно
забрать запись; хранилище читает кэш напрямую, поэтому запись пересекает транспорт один раз —
как байты, которые никто повторно не кодирует.

поток рабочего процесса ─► очередь ─► средство записи журнала ─► valkey
                                                     │
                                                     └─ commitLog([keys]) ─► rp-dag ─► хранилище читает valkey
                                                                                              │
                                                     ◄──── зафиксировано ─────────────────────┘
                                                     └─ удалить зафиксированные ключи

Именно это убирает журналирование с критического пути рабочего процесса: узел требует от
среды выполнения только добавления в очередь и ничего больше. Это также означает, что журнал
по своей природе работает по принципу best effort — при обратном давлении запись может быть
отброшена, а пакет после сбоя может быть зафиксирован дважды. Ключи производятся из запуска
и последовательности узла, поэтому вторая фиксация является перезаписью, а не дубликатом.

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

dag:log:<executionId>:exec — запуск
dag:log:<executionId>:n:<seq> — один из его узлов, дополненный нулями слева до шести цифр

commitLog выводит расположение хранилища из ключа и отклоняет всё, что находится за пределами
префикса dag:log:, поэтому ключ — это весь объём полномочий, который несёт вызов.

Журнал является деревом

exec:<id>              запуск
node:<id>:<seq>        его узлы в порядке их открытия

Узел, который делегировал выполнение через rt.sub, содержит идентификатор дочернего запуска,
а дочерний запуск является обычным запуском со своими узлами. executionTree обходит эту связь
в глубину и возвращает результат в плоском виде, помечая каждую строку её depth — поэтому
клиент отображает дерево только за счёт отступов. Индекс родителя не нужен: связь хранится в
узле, который её создал.

Последовательности дополняются нулями слева в ключе, поскольку KV-хранилище возвращает диапазон
по префиксу в лексикографическом порядке, а этот порядок должен совпадать с порядком выполнения
узлов. Среда выполнения дополняет число до такой же ширины при составлении ключа кэша; эти две
ширины являются единым контрактом.

Срок хранения ограничен числом запусков (5000 по умолчанию) и проверяется при каждом сотом
открытии. Журнал предназначен для диагностики, а не для архивирования.

Изменения триггеров достигают среды выполнения через шину

Создание, изменение или удаление триггера публикует dag.triggers.changed. Среда выполнения
подписывается на эту тему наряду с собственными темами триггеров, поэтому изменение становится
активным для следующего события, не дожидаясь окончания интервала опроса. Публикация выполняется
по принципу best effort — неработающая шина не должна приводить к сбою изменения оператора —
а периодическое обновление среды выполнения остаётся резервным механизмом.

Прямые зависимости модулей

g-bus — для объявления об изменении триггера

Членство в Solution

Не включён ни в одно предопределённое решение

Исходный код

modules/repositories/automation/rp-dag