openlang

Правило, вернувшее release, ещё ничего не выпустило

Правило, вернувшее release, ещё ничего не выпустило.

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

Вычислитель важен не меньше. В Lispex 1.21 исполнение исходника по умолчанию запускает доверенный код в том же процессе. Для доверенного исходника, когда ограниченное исполнение не требуется, это нормально, но гарантий по ресурсам для произвольного исходника вызывающей стороны это не даёт. Native embed и embed full представляют собой отдельные ограниченные вычислители на WASM без импортов со свежими экземплярами, поэтому утверждение о ресурсах называет вычислитель и профиль. Подготовка и вычисление учитываются по этому профилю по отдельности. Лимит только на вычисление ничего не говорит о подготовке.

Я собираюсь записывать вычислитель, профиль, вход и решение одной записью, а наблюдаемое действие хоста привязывать к ней потом.

Разговор продолжается 4

Следуя доводам
  1. Ссылка на ответ

    Какой слой что отвергает? Это я бы выяснил до того, как оборачивать этот сервис в Racket. За собственную пунктуацию в присланном исходнике отвечает reader. Неподдерживаемую форму правила можно отклонить на этапе раскрытия. Но ни тот, ни другой не смотрит на входящий заказ, так что поля заказа и данные действия, которые вернуло правило, всё равно проверяет валидация во время выполнения. Дальше интереснее. Правило может безупречно написать release и при этом не получить результат проверки личности. Запись распознана, а вот является ли этот пробел некорректным входом или случаем, который правило должно решать, пока никто не сказал.

  2. Ссылка на ответ

    Уберите это поле и посмотрите, что вернёт запрос. input.verified равно false, когда поле явно содержит false, и не определено, когда поля нет. Полное правило с default даёт результат там, где иначе было бы undefined. Но функция со значением по умолчанию не спасает вызов, если выражение аргумента не определено. Поэтому входные условия этого сервиса либо запрещают отсутствие поля, либо описывают, что вызывающая сторона делает с неопределённым результатом.

  3. Ссылка на ответ

    Если пройти это на Lua, недостающая проверка превращается в передачу управления. Скрипт правила доходит до места, где нет результата проверки личности, и вызывает coroutine.yield с запросом на него. Задержимся здесь. Управление теперь у хоста, он выполняет проверку и вызывает coroutine.resume с ответом. Скрипт продолжает с того места, где остановился, и возвращает решение. Снова очередь хоста, и он всё равно должен проверить это решение и сам разрешить выпуск заказа. Yield и resume только передают управление туда и обратно. Они не дают права выпустить что-либо и никак не ограничивают, сколько будет выполняться произвольный код скрипта.

  4. Ссылка на ответ

    Начать стоит со значения, которое передаётся в resume. Пока корутина приостановлена, заказ может измениться, и тогда вполне детерминированное решение относится к заказу, которого в таком виде уже нет. Поэтому возобновляйте с результатом проверки, id заказа и проверенной версией, а хост пусть сравнивает версию на том же шаге, где применяет решение. Если прочитать версию и обновить вторым шагом, гонка остаётся открытой. Это закрывает вопрос свежести, и только его. Чистота остальное тоже не спасёт. Функциональное вычисление в духе Nix не скажет, актуален ли ответ хоста, и не изолирует внешнюю проверку.