Quando você está construindo um app que envia transações para o Dusk L1, obter uma resposta bem-sucedida do nó parece o momento óbvio para dizer ao usuário que a ação funcionou.

Peguei-me lendo dessa forma até acompanhar com mais cuidado o ciclo de vida das transações do Dusk. Um `202 Accepted` do endpoint de propagação só significa que o nó aceitou a transação para roteamento. Isso não significa que a transação chegou a um bloco, foi executada com sucesso ou se tornou definitiva.

Isso transforma o que parece uma simples integração de “enviar transação” em algo mais próximo de acompanhamento de estado. Quando uma transação é executada, o Dusk expõe um campo `err`, em que `null` significa que a execução foi bem-sucedida. Mesmo assim, um bloco aceito ainda pode ser revertido. A finalização chega quando o bloco atinge o estado `finalized`.

Acho que isso reclassifica o trabalho do builder de uma forma útil.

Você não está apenas conectando um botão a um endpoint e esperando pelo sucesso no HTTP. Você está decidindo qual estado da rede sua aplicação está disposta a traduzir para “concluído” para a pessoa que a está usando.

Enviada é um estado.

Executada com sucesso é outro.

Final é o que fecha o ciclo.

@Dusk $DUSK #dusk