Когда вы разрабатываете приложение, отправляющее транзакции в Dusk L1, успешный ответ от ноды кажется очевидным моментом, чтобы сообщить пользователю, что действие выполнено.

Я и сам какое-то время читал это именно так, пока не разобрался с жизненным циклом транзакций в Dusk внимательнее. `202 Accepted` с endpoint’а propagation лишь означает, что нода приняла транзакцию для маршрутизации. Это не значит, что транзакция дошла до блока, успешно выполнилась или стала финальной.

Из-за этого “простая” интеграция отправки транзакций превращается во что-то ближе к отслеживанию состояния. После выполнения транзакции Dusk предоставляет поле `err`: `null` означает, что выполнение прошло успешно. Даже тогда принятый (accepted) блок всё ещё может быть отменён (reverted). Финальность наступает, когда блок переходит в состояние `finalized`.

Мне кажется, это полезно переопределяет задачу билдера.

Вы не просто подключаете кнопку к endpoint’у и ждёте, пока HTTP-запрос завершится успешно. Вы решаете, какое именно сетевое состояние ваше приложение готово считать для пользователя “завершённым”.

Submitted — это одно состояние.

Executed successfully — другое.

Final — то, что замыкает цикл.

@Dusk $DUSK #dusk