Ценность Durable Task заключается не в замене каждого фонового рабочего процесса, очереди сообщений или базы данных, а в организации операций, которые длятся долго, приостанавливаются в ожидании внешнего события или могут прерваться после выполнения части шагов. В блоге .NET представлены пять практических примеров с использованием пакета Durable Task .NET SDK версии 1.26.0 вместе с Durable Task Scheduler; при этом подчёркивается, что инструмент сохраняет историю координации, но не восстанавливает приостановленный стек выполнения CLR.
Центральная идея состоит в разделении того, что координирует движок рабочего процесса, и того, за что отвечает приложение. Durable Task может сохранять точки прогресса, ожидать, не удерживая занятый поток выполнения, и повторно запускать код оркестратора на основе записанных результатов. Но он не определяет полномочия пользователей, не гарантирует выполнение внешних эффектов ровно один раз и сам по себе не определяет, какие ресурсы безопасно удалять или действительно ли платёж был получен.
Утверждение человеком не означает остановку рабочего процесса
При обработке счетов можно запускать каждый счёт в рамках отдельной дочерней координации. Счета, не требующие проверки, продолжают обработку, тогда как счёт, требующий утверждения человеком, ожидает внешнего события и надёжного тайм-аута. Если рабочий процесс остановится, другой рабочий процесс сможет повторно запустить оркестратор и вернуться к точке ожидания вместо ручного восстановления состояния.
Однако событие утверждения является лишь сигналом. Документированная конечная точка должна атомарно записать окончательное решение в хранилище приложения до отправки сигнала, а шаг бухгалтерского учёта должен проверять идентификатор стабильного развертывания и неизменяемый отпечаток запроса. Если бухгалтерская запись принята, а подтверждение выполнения действия потеряно, одной истории Durable Task недостаточно для предотвращения повторения; необходим протокол сверки с бухгалтерской системой.
Подготовка среды Azure: где заканчивается роль ARM?
В материале отмечается, что ARM и Bicep могут быть достаточны для развертывания определённых ресурсов, поскольку они обеспечивают упорядочивание зависимостей, параллельное выполнение и повторное применение требуемого состояния со стабильными идентификаторами. Поэтому добавление Durable Task не оправдано, если оно лишь воссоздаёт схему развертывания, которую ARM уже предоставляет.
Преимущество появляется, когда процесс выходит за рамки развертывания ресурсов и включает принятие запроса арендатора, уведомление его о ходе выполнения, ожидание готовности, а затем активацию арендатора. В примере предлагается сохранять запрос на подготовку и его идентификаторы в базе данных приложения с outbox, а затем использовать координацию, связывающую этапы работы с сетью, базой данных, хранилищем, приложением и DNS, а также проверку готовности. Сами операции Azure по-прежнему требуют журналов операций, стабильных идентификаторов и сверки при потере ответов.
Материал предостерегает от того, чтобы считать компенсацию кнопкой отмены. Azure может всё ещё создавать базу данных после сбоя хранилища. Поэтому необходимо не позволять старой попытке запускать новые операции, проверять ранее отправленные операции и удалять только ресурсы, принадлежащие исключительно этой попытке, после подтверждения отсутствия отложенных операций, которые могут создать их заново. Если состояние или принадлежность невозможно доказать, безопасным результатом будет NeedsIntervention, а не удаление на основании предположения.
Истечение тайм-аута платежа — не отказ
В цикле подписки ответ платёжного провайдера может исчезнуть после принятия операции. Немедленная повторная попытка может привести к двойному списанию, тогда как признание операции отклонённой может отправить вводящее в заблуждение уведомление. В примере предлагается связывать каждый платёжный цикл с идентификатором цикла и стабильным ключом платежа, а затем использовать надёжные таймеры, обратные вызовы, периодические проверки и установленный льготный период.
Авторитетным источником состояний Unknown, Pending, Declined, Paid и NotCharged остаётся журнал платежей. Следующий цикл не начинается до подтверждения квитанции и закрытия текущего цикла. Если срок истёк, а состояние осталось неразрешённым, результатом должно быть NeedsReconciliation, а не предположение об успехе или отказе платежа.
Поздние события требуют защиты на стороне назначения
При обновлении поискового индекса новостных статей версия 12 может поступить после версии 13 или операции индексации могут завершиться в обратном порядке. Durable Entity может сохранять максимальную увиденную версию и последовательность обновления счётчиков, но он не блокирует внешний индекс и не предотвращает параллельную запись двух запросов.
Поэтому само назначение должно обеспечивать атомарный барьер версий, отклоняющий запись более старой версии после фиксации новой. Системе также нужны надёжный inbox, распределитель для продолжения обработки и периодическая сверка с источником. Даже шаблон оркестратора с одним идентификатором не даёт гарантии выполнения внешних эффектов ровно один раз.
Что это означает для ИИ-агентов?
В рабочем процессе помощника по инцидентам необходимо сохранять конкретное предложение модели, ожидать его утверждения инженером, а затем выполнять одобренный инструмент после возможного сбоя. Ценность здесь заключается в восстановлении самого пути согласования и решения, а не в повторной генерации нового предложения при каждом перезапуске. Идентификатор предложения, допустимость инструмента и предотвращение выполнения устаревшего или дублирующегося запроса остаются ответственностью приложения.
Практический вывод из пяти примеров состоит в том, что Durable Task подходит, когда сохранение «того, что произойдёт дальше» само становится отдельной системой. Если же приложение уже располагает очередями, таймерами и понятными журналами сверки или если внешняя система обеспечивает надёжную координацию, как ARM, фреймворк может добавить больше сложности, чем ценности. Кроме того, все примеры опираются на явно заданные внешние границы: авторитетную запись, ключ idempotency, барьер версий, outbox или протокол сверки.