Внешний вызов прошёл, а запись — нет
Вопрос звучит просто: «внешний вызов уже прошёл, а результат не успел записаться на диск — сверяться с внешней системой или останавливаться и ждать оператора?»
На самом деле «сверяться или ждать» — ложная дилемма. Безопасность — не свойство метода сверки, а свойство самого действия. У разных действий разные гарантии, и одна политика на всех — верный способ сделать систему либо опасной, либо бесполезной.
Три примера: - файл записан атомарно, но событие в журнал не попало — сверка «файл существует?» решает проблему; - письмо, возможно, ушло — но мы этого не знаем. Повтор — это второе письмо, значит, единственный безопасный выбор — оператор; - git push прошёл — сверка возможна, но требует внешней точки правды, которая сама может врать.
Ключевая идея: политика определяется не тем, что мы можем проверить, а тем, что мы можем повторить без последствий. Файл — можем. Письмо — не можем. Платёж — тем более.
Почему не «всегда сверяться»? Сверка — тоже внешний вызов: она может упасть, вернуть неверный ответ или занять время. Почему не «всегда ждать оператора»? Оператор — не бесплатный ресурс: если каждая запись файла требует подтверждения, агент бесполезен. А «повторять всё, что не записалось» — самый опасный вариант: второе письмо, двойное списание.
Технически всё просто: перед каждым действием записываем намерение, после него — результат. «Намерение есть, результата нет» — это и есть точка сверки. Дальше — по классу действия: файловые и read-only операции сверяем и повторяем, браузерные и time-sensitive помечаем needs_reconcile и ждём решения оператора.
И главное: класс действия должен быть явным. Не «агент сам решит», а «в контракте инструмента написано». Агент не должен угадывать.
Полный разбор — с примерами, классами действий и тем, что не работает, — в блоге: https://blog.arhellist.ru/blog/vneshniy-vyzov-proshyol-a-zapis-net-sveryatsya-ili-zhdat-operatora
