Modèle d’exécution
Une instance progresse à partir des dépendances explicites du graphe. Un node ne devient exécutable que lorsque son chemin actif et ses prédécesseurs le permettent ; des branches indépendantes peuvent avancer en parallèle, et une attente suspend l’instance sans perdre son état ni rejouer les steps déjà terminés.
Cycle de vie d’une instance
| État | Signification |
|---|---|
running | L’instance peut continuer son exécution. |
waiting | L’instance attend une échéance, une interaction, un événement ou une exécution enfant. |
stopping | Un arrêt a été demandé pendant qu’une exécution active doit encore céder la main proprement. |
completed | Le processus a atteint une fin réussie et son output est disponible. |
failed | Une erreur terminale empêche cette tentative de continuer. |
retry_exhausted | Une opération rejouable a épuisé son budget de retry durable. |
superseded | Une continuation corrective a remplacé cette instance dans sa lignée. |
stopped | L’instance a été arrêtée explicitement. |
Ces états décrivent l’exécution d’un process_instance. Ils ne sont pas les statuts métier de la commande, de la facture, du retour ou de toute autre ressource traitée par le processus.
États persistés des steps
L’historique durable d’une instance conserve un step lorsqu’un node atteint un résultat observable. Les états persistés actuels sont les suivants ; un node qui n’a pas encore été atteint n’a pas besoin d’un steppending matérialisé.
| État | Signification |
|---|---|
completed | Le node a terminé et ses sorties durables sont disponibles. |
waiting | Le node a matérialisé une attente et reprendra lorsque cette attente sera satisfaite. |
failed | Le node n’a pas pu produire une sortie utilisable pour cette tentative. |
skipped | Le node n’a pas été exécuté parce que sa branche est inactive ou qu’un ancêtre a rendu ce chemin impossible. |
cancelled | Une attente ou un step encore actif a été interrompu, par exemple lors de l’arrêt d’une instance. |
Dépendances et parallélisme
Après A, B et C n’ont pas de dépendance entre eux et peuvent progresser indépendamment. D ne devient disponible qu’une fois ses prédécesseurs actifs satisfaits.
Dans un chemin linéaire A → B → C, l’ordre est strict. Lorsque plusieurs branches actives partent d’un même point et n’ont pas de dépendance entre elles, leur exécution peut se chevaucher ; ne comptez donc pas sur un ordre implicite entre deux branches parallèles.
À une convergence, le node aval attend les prédécesseurs qui appartiennent réellement au chemin actif. Cette même structure est utilisée pour vérifier les ancêtres garantis.
Routage et branches inactives
Un node routeur sélectionne une continuation explicite. Les branches non sélectionnées ne sont pas exécutées ; leurs descendants qui ne sont plus atteignables deviennent skipped. Une route choisie fait partie du résultat de cette exécution du node et reste stable lorsque l’instance reprend après une attente.
Une sortie produite uniquement dans une branche conditionnelle ne devient donc pas automatiquement disponible après la convergence. Voir Routage et décisions.
Suspensions et reprises
Une attente durable place le step concerné et l’instance en waiting. L’état nécessaire à la continuation est conservé ; lorsque le signal attendu arrive, l’instance reprend à partir de cette attente au lieu de recommencer depuis le début.
| Famille | Ce qui peut être attendu |
|---|---|
| Timer | Wait ou retry durable jusqu’à une échéance. |
| Action utilisateur | Formulaire, choix, affichage ou interaction d’extension présentée au participant. |
| Approbation | Décision humaine portée par une approval_request. |
| Événement | Attente d’un événement plateforme ou d’extension corrélé. |
| Sous-processus / Foreach | Attente d’une ou plusieurs instances enfants selon la politique configurée. |
| Agent Run | Attente de la fin de l’exécution interne d’un Agent task. |
| External Task | Attente du résultat typé fourni par un service externe autorisé. |
Une attente réussie produit la sortie du node puis débloque les continuations qui en dépendent. Les steps déjàcompleted restent terminés et ne sont pas rejoués simplement parce que l’instance a été suspendue.
Erreurs et propagation
Lorsqu’un node échoue définitivement, son step devient failed et les continuations qui dépendent de ce résultat ne sont pas exécutées. Une branche indépendante déjà exécutable n’est pas transformée rétroactivement en échec parce qu’une autre branche a rencontré une erreur.
Avant de rendre l’échec terminal, Ormuz peut planifier un retry durable lorsque l’erreur est explicitement classée comme rejouable et que l’opération est sûre à rejouer. Pendant cette attente de retry, le node restewaiting. Le détail du budget et des garanties d’idempotence est dans Erreurs, retries et idempotence.
État process vs état métier
Certaines ressources process-owned — par exemple un onboarding, un litige ou un retour — conservent la relation avec l’instance qui porte leur traitement. Cette relation n’assimile jamais le statut de l’instance au statut de la ressource.
completed signifie que le contrat du processus s’est terminé correctement ; cela ne doit pas être interprété comme « facture payée », « retour accepté » ou « onboarding approuvé » sans la transition métier correspondante. De même, un arrêt de l’instance n’invente pas automatiquement une annulation métier.