Outbox: коробка недоделанных побочных эффектов

Агент решил отправить задачу другой группе или записать файл, и тут процесс упал. Сделалось действие или нет? В Элис на это отвечает outbox — «коробка недоделанных побочных эффектов».

Как это устроено и почему идемпотентность здесь важнее скорости.

Идея. Действие, которое меняет мир, сначала кладёт в state.db запись «надо сделать». Потом выполняется. Потом запись закрывается. После рестарта система первым делом разбирает pending: доделывает или честно закрывает.

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

Связь с журналом. Outbox живёт в state.db, а state.db — проекция журнала. Поэтому намерение и результат видны и в аудите, и при replay.

Связь со стартом задачи. Восстановление outbox — обязательный шаг запуска, до того как группа возьмёт новую работу. Нельзя начинать новое, не разобравшись с хвостами старого.

Ключевая трудность (инженерная): не все действия идемпотентны. Записать файл тем же содержимым можно ещё раз. Передать задачу на другой хост или отправить что-то наружу — нет: повтор создаёт дубль. У каждого типа эффекта должна быть своя стратегия: повторить, сверить с внешней стороной по ключу или закрыть как невыполненное и сказать об этом. Универсального «retry» тут нет, и честнее закрыть pending с причиной, чем молча задвоить.

Дальше — как стартует задача: от команды до первого вызова модели.

Мой Телеграм