Кратко

  • Редакция 04 проекта SAMP добавляет record_revision к результатам операций CONFIG и EXEC. При существенном изменении результата номер растёт, прежние снимки сохраняются в дополняемой истории аудита. В редакции 03 этого поля не было.
  • Позднее подтверждение успеха требует доказательства эффекта именно исходной операции. Точное повторение запроса возвращает последнюю запись без повторного исполнения. Если конечная точка не может установить последнюю зафиксированную ревизию, она отвечает back_pressure без результата.

Новая запись вместо чистой страницы

Дежурный посылает агенту команду поменять параметр. Ответ обрывается на «неизвестно». Следующая смена видит нужное значение и ставит отметку «сделано». Но значение мог изменить другой оператор. Пульт видит состояние, а журнал обязан указать причинную связь. Иначе запись о работе превращается в самоуверенную догадку.

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

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

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

Карточка IETF относит текст к индивидуальному проекту с предполагаемым статусом Experimental. Проверить реальную реализацию помогла бы аутентифицированная трасса от неопределённого ответа через позднее доказательство и повышение ревизии до восстановления после перезапуска.

Источники: редакция 04; редакция 03; статус IETF.