Cuando estás construyendo una aplicación que envía transacciones a Dusk L1, obtener una respuesta exitosa del nodo parece el momento obvio para decirle al usuario que la acción funcionó.

Me sorprendí leyéndolo así hasta que seguí con más cuidado el ciclo de vida de las transacciones de Dusk. Un `202 Accepted` desde el endpoint de propagación solo significa que el nodo aceptó la transacción para el enrutamiento. No significa que la transacción haya llegado a un bloque, se haya ejecutado con éxito o se haya vuelto definitiva.

Eso convierte lo que parece una integración simple de “enviar transacción” en algo más parecido al seguimiento de estado. Cuando una transacción se ejecuta, Dusk expone un campo `err`, donde `null` significa que la ejecución fue exitosa. Aun así, un bloque aceptado todavía puede revertirse. La definitividad llega cuando el bloque alcanza el estado `finalized`.

Creo que esto reclasifica el trabajo del constructor de una forma útil.

No solo estás conectando un botón a un endpoint y esperando el éxito de HTTP. Estás decidiendo qué estado de la red tu aplicación está realmente dispuesta a traducir como “completo” para la persona que la utiliza.

Enviado es un estado.

Ejecutado con éxito es otro.

Final es el que cierra el ciclo.

@Dusk $DUSK #dusk