Summary

  • Новая редакция индивидуального Internet-Draft от 27 октября предлагает decision.operationKey: повторные попытки выполнить одно поручение сохраняют ключ, отдельное поручение получает другой.
  • В примере проекта при лимите 500 фунтов уже израсходовано 300 и зарезервировано 120. Повтор оставляет обязательство на уровне 420; новый платёж на 120 доводит его до 540.

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

В редакции -02 проекта каждой задуманной операции предлагается присваивать decision.operationKey и включать его в подписанный запрос. Настоящий повтор несёт старый ключ. Новое поручение получает новый, даже если текст и параметры идентичны. Ключ действует в пределах конкретного лимита, обозначенного limitDigest. Так запись связывает решение с той делегированной суммой, которую оно способно потратить.

Редакция -01 определяла повтор по хешу самого запроса. Авторы новой редакции указывают, что хеш охватывает действие, аргументы и ресурс, а потому совпадает у двух отдельно задуманных платежей с одинаковым содержанием. Второй платёж мог не попасть в накопленный расход, словно он лишь эхо первого.

Пример документа проверяет это числами, без всякой магии. Лимит — 50 000 пенсов. Уже потрачено 30 000; разрешение на 12 000 остаётся в резерве после потери ответа. Если приходит повтор с тем же ключом, общая занятая сумма равна 42 000. Если приходит новое поручение на 12 000 с другим ключом, получается 54 000, выше предела. Одинаковый хеш запроса не превращает вторую финансовую обязанность в первую.

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

Молчание инструмента также не освобождает деньги. Резерв переносится в расход, когда запись той же операции сообщает о совершившемся эффекте, или снимается, когда запись подтверждает отсутствие эффекта. Тот, кто хранит последовательность записей, сравнивает версии состояния: позднее разрешение, выданное на старых данных и не заметившее прежний резерв, выдаёт окно двойного обещания.

Реестр IETF показывает индивидуальный Internet-Draft в состоянии I-D Exists. Предложение ещё обсуждается. Оно уже формулирует полезный вопрос: кто отвечает за то, чтобы автоматический распорядитель чужого лимита не называл второе обещание повтором первого?