Является ли тест в функции Durable Azure Orchestrator недетерминированным, если при повторном запуске тест может дать другой результат?
Этот вопрос касается детерминизма в функции оркестратора Azure, которая выполняет некоторые обновления сторонней системы при изменении объекта в той же сторонней системе.
Я рассматриваю возможность использования устойчивых функций Azure, управляемых функцией оркестратора, со следующей схемой:
Вебхук получает старую и новую версии объекта и запускает функцию оркестратора. Функция оркестратора начинается с вызова функции действия, которая возвращает логическое значение, если требуются некоторые обновления. Важно то, что критерии, определяющие обновления, вызывают внешние API, которые могут давать разные результаты при повторном запуске функции оркестратора.
Является ли это недетерминированным и вызывает ошибки «обнаружен недетерминированный рабочий процесс»? Или это сработает, потому что я отправил тесты в функцию активности, которая возвращает логическое значение, а логика функции оркестратора не изменилась?
Другими словами, может ли ограничение детерминизма в функции Azure блокировать логику функции оркестратора, которая может иметь разные пути при повторном запуске?
Я рассмотрел это Ограничения кода функции оркестратора
Ответы 1
Вебхук получает старую и новую версии объекта и запускает функция оркестратора. Функция оркестратора начинается с вызова функция активности, которая возвращает логическое значение, если требуются некоторые обновления. Важно то, что критерии, определяющие обновления, вызывают внешние API, которые могут давать разные результаты при повторном запуске функция оркестратора.
Является ли это недетерминированным и причиной «недетерминированного рабочего процесса»? обнаружены" ошибки? Или это будет работать, потому что я отправил тесты в функция активности, которая возвращает логическое значение и логику в функция оркестратора не изменилась?
Результаты функции активности сохраняются в таблице истории. При повторах действие не выполняется повторно; вместо этого результат извлекается из таблицы истории. Конечно, если вы запустите новый экземпляр оркестратора, он запустит действие, поскольку для этого экземпляра не существует истории. Реализация правильная и детерминированная.
Действия запускаются только один раз, когда все идет нормально. Если что-то пойдет не так внутри устойчивых функций, действие может запуститься более одного раза. Идемпотентность обычно является хорошим свойством.
Спасибо! Будет ли при воспроизведении функция активности внизу справа, которая «заставляет обновление» запускаться снова на основе результата повтора оценки изменений, извлеченного из истории? Это должно быть идемпотентно?