Quand vous construisez une application qui soumet des transactions à Dusk L1, obtenir une réponse réussie du nœud semble être le moment évident pour dire à l’utilisateur que l’action a fonctionné.
Je me suis surpris à le lire ainsi, jusqu’à ce que je suive plus attentivement le cycle de vie des transactions de Dusk. Un `202 Accepted` provenant de l’endpoint de propagation signifie seulement que le nœud a accepté la transaction pour l’acheminement. Cela ne veut pas dire que la transaction est arrivée dans un bloc, qu’elle a été exécutée avec succès ou qu’elle est devenue finale.
Cela transforme une intégration qui semblait simple « envoyer une transaction » en une forme plus proche du suivi d’état. Une fois qu’une transaction s’exécute, Dusk expose un champ `err`, où `null` signifie que l’exécution a réussi. Même alors, un bloc accepté peut encore être annulé. La finalité arrive lorsque le bloc atteint l’état `finalized`.
Je pense que cela requalifie utilement le rôle du concepteur.
Vous ne faites pas que connecter un bouton à un endpoint et attendre un succès HTTP. Vous décidez quel état du réseau votre application est réellement prête à traduire en « terminé » pour la personne qui l’utilise.
« Soumise » est un état.
« Exécutée avec succès » en est un autre.
« Finale » est celle qui clôt la boucle.
@Dusk $DUSK #dusk
Je me suis surpris à le lire ainsi, jusqu’à ce que je suive plus attentivement le cycle de vie des transactions de Dusk. Un `202 Accepted` provenant de l’endpoint de propagation signifie seulement que le nœud a accepté la transaction pour l’acheminement. Cela ne veut pas dire que la transaction est arrivée dans un bloc, qu’elle a été exécutée avec succès ou qu’elle est devenue finale.
Cela transforme une intégration qui semblait simple « envoyer une transaction » en une forme plus proche du suivi d’état. Une fois qu’une transaction s’exécute, Dusk expose un champ `err`, où `null` signifie que l’exécution a réussi. Même alors, un bloc accepté peut encore être annulé. La finalité arrive lorsque le bloc atteint l’état `finalized`.
Je pense que cela requalifie utilement le rôle du concepteur.
Vous ne faites pas que connecter un bouton à un endpoint et attendre un succès HTTP. Vous décidez quel état du réseau votre application est réellement prête à traduire en « terminé » pour la personne qui l’utilise.
« Soumise » est un état.
« Exécutée avec succès » en est un autre.
« Finale » est celle qui clôt la boucle.
@Dusk $DUSK #dusk
