Je suppose que par « désengagent/Annuler la gestion du service de portail » vous faites référence à la suppression du service via l'application Web du Service Fabric Explorer (peut-être via un lien suivi du portail). S'il vous plaît corrigez-moi si c'est faux.
Pour répondre directement à votre question, le cadre n'attendra pas que les opérations en vol se terminent lors d'une suppression de service. Chaque réplique du service perd ses autorisations de lecture et d'écriture, ce qui entraîne l'échec de toutes les opérations en vol. Nous n'offrons pas de moyen de bloquer cette étape afin, par exemple, de permettre l'achèvement des transactions en cours.
La raison pour laquelle nous n'offrons pas cette sémantique est que la suppression de service devrait être rare ou permanente, et que la suppression retardée pour l'opération finale n'autorise aucun scénario supplémentaire. Dans les deux cas, si un client tente des opérations sur un service en cours de suppression, soit:
- La dernière opération client peut échouer en raison de supprimer la course et révocation des autorisations de lecture/écriture
- Chaque opération client ultérieure échouera en raison au service existant ne
ou
- la dernière opération client réussira en raison de la suppression étant retardée
- Chaque opération client ultérieure échouera à cause du service n'existant
L'attente est que tout client ou service dépendant devraient déjà avoir été mis à jour ou supprimé avant la suppression du service dont ils dépendent, comme vous faites la décision permanente que ce service ne devrait plus exister.
En plus de la réponse de tyadams, nous trouvons qu'il est utile de copier la référence au cancelToken donné à la méthode RunAsync et de l'utiliser dans toutes nos méthodes asynchrones. Donc, au moins, nous pouvons gracieusement fermer toutes les activités lorsque le tissu arrête le service. –