La valeur de Durable Task ne réside pas dans le remplacement de chaque worker en arrière-plan, file de messages ou base de données, mais dans l’organisation des opérations qui s’étendent sur une longue durée, s’interrompent dans l’attente d’un événement externe ou peuvent être interrompues après l’exécution d’une partie de leurs étapes. Le blog .NET présente cinq exemples pratiques utilisant le package Durable Task .NET SDK version 1.26.0 avec Durable Task Scheduler, en soulignant que l’outil conserve l’historique de l’orchestration et ne restaure pas une pile d’exécution CLR suspendue.
L’idée centrale consiste à séparer ce que le moteur de workflow orchestre de ce qui reste sous la responsabilité de l’application. Durable Task peut enregistrer les points de progression, attendre sans maintenir un thread d’exécution occupé et rejouer le code de l’orchestrateur en fonction des résultats enregistrés. En revanche, il ne décide pas des autorisations des utilisateurs, ne garantit pas l’exécution unique des effets externes et ne détermine pas à lui seul quelles ressources peuvent être supprimées en toute sécurité ni si un paiement a réellement été reçu.
Une approbation humaine ne signifie pas arrêter le worker
Dans le traitement des factures, chaque facture peut être exécutée dans le cadre d’une orchestration enfant indépendante. Les factures qui ne nécessitent pas de vérification poursuivent leur traitement, tandis que la facture nécessitant une approbation humaine attend un événement externe et une échéance durable. Si le worker s’arrête, un autre worker peut rejouer l’orchestrateur et revenir au point d’attente au lieu de reconstruire manuellement l’état.
Toutefois, l’événement d’approbation n’est qu’un signal. Un point de terminaison authentifié doit enregistrer la décision finale de manière atomique dans le stockage de l’application avant d’envoyer le signal, et l’étape comptable doit vérifier une identité de publication stable ainsi qu’une empreinte de requête immuable. Si l’écriture comptable est acceptée puis que la confirmation de l’activité est perdue, l’historique de Durable Task ne suffit pas à empêcher la duplication ; un protocole de rapprochement avec le système comptable est alors nécessaire.
Configuration d’un environnement Azure : où s’arrête le rôle d’ARM ?
L’article explique qu’ARM et Bicep peuvent suffire pour déployer des ressources déterminées, puisqu’ils fournissent l’ordre des dépendances, l’exécution parallèle et la réapplication de l’état souhaité avec des identités stables. Par conséquent, l’ajout de Durable Task ne se justifie pas pour reconstruire un schéma de déploiement qu’ARM fournit déjà.
L’intérêt apparaît lorsque le parcours dépasse le déploiement des ressources pour inclure l’acceptation d’une demande du locataire, la communication de sa progression, l’attente de la disponibilité, puis l’activation du locataire. L’exemple propose d’enregistrer la demande de configuration et ses identifiants dans la base de données de l’application avec une outbox, puis d’utiliser une orchestration reliant les étapes du réseau, de la base de données, du stockage, de l’application et du DNS, ainsi que la vérification de disponibilité. Les opérations Azure elles-mêmes nécessitent toujours des journaux d’opérations, des identités stables et un rapprochement en cas de perte des réponses.
L’article met également en garde contre le fait de considérer la compensation comme un bouton d’annulation. Azure peut encore être en train de créer une base de données après l’échec du stockage. Il faut donc empêcher l’ancienne tentative de lancer de nouvelles opérations, vérifier les opérations envoyées précédemment et supprimer uniquement les ressources exclusivement détenues par la tentative après s’être assuré qu’aucune opération en retard ne risque de les recréer. S’il est impossible de prouver l’état ou la propriété, le résultat sûr est NeedsIntervention, et non une suppression conjecturale.
L’expiration du délai de paiement n’est pas un refus
Dans le cycle d’abonnement, la réponse du fournisseur de paiement peut disparaître après l’acceptation de l’opération. Réessayer immédiatement peut entraîner un double prélèvement, tandis que considérer l’opération comme refusée peut envoyer une notification trompeuse. L’exemple propose d’associer chaque cycle de paiement à un identifiant de cycle et à une clé de paiement stable, puis d’utiliser des minuteurs durables, des callbacks, des vérifications périodiques et un délai de grâce défini.
Le registre des paiements reste la source authoritative pour les états Unknown, Pending, Declined, Paid et NotCharged. Le cycle suivant ne commence qu’après la confirmation du reçu et la clôture du cycle actuel. Si le délai expire alors que l’état reste indéterminé, le résultat est NeedsReconciliation plutôt que la supposition que le paiement a réussi ou échoué.
Les événements tardifs nécessitent une protection à la destination
Lors de la mise à jour d’un index de recherche pour des articles d’actualité, la version 12 peut arriver après la version 13, ou les opérations d’indexation peuvent se terminer dans l’ordre inverse. L’entité durable peut conserver la version la plus élevée observée et séquencer les mises à jour de ses compteurs, mais elle ne verrouille pas l’index externe et n’empêche pas deux requêtes d’écrire en parallèle.
La destination doit donc elle-même imposer une barrière de version atomique qui refuse l’écriture d’une version plus ancienne après l’établissement d’une version plus récente. Le système a également besoin d’une inbox fiable, d’un répartiteur de suivi et d’un rapprochement périodique avec la source. Même le modèle d’orchestrateur doté d’un identifiant unique n’offre pas de garantie d’exécution unique pour les effets externes.
Qu’est-ce que cela signifie pour les agents d’intelligence artificielle ?
Dans un workflow d’assistance aux incidents, le processus doit conserver la suggestion précise du modèle, attendre son approbation par l’ingénieur, puis exécuter l’outil approuvé après une éventuelle interruption. La valeur réside ici dans la reprise du même parcours d’approbation et de décision, et non dans la régénération d’une nouvelle suggestion après chaque redémarrage. En revanche, l’identité de la suggestion, la validité de l’outil et la prévention de l’exécution d’une requête ancienne ou dupliquée restent sous la responsabilité de l’application.
La conclusion pratique des cinq exemples est que Durable Task convient lorsque la conservation de « ce qui se passera ensuite » devient en soi un système. En revanche, si l’application dispose déjà de files d’attente, de minuteurs et de journaux de rapprochement clairs, ou si le système externe fournit une orchestration fiable telle qu’ARM, le framework peut ajouter davantage de complexité que de valeur. Tous les exemples reposent également sur des frontières externes explicites : un registre faisant autorité, une clé d’idempotence, une barrière de version, une outbox ou un protocole de rapprochement.