#dusk $DUSK @Dusk
Мне пришлось перечитать это дважды, потому что HTTP 202 Accepted обычно заставляет мозг расслабиться.
Но на Dusk, вероятно, не стоит.
Когда /transactions/propagate возвращает 202 Accepted, узел принял транзакцию для маршрутизации.
Одного этого недостаточно, чтобы доказать, что транзакция:
попала в реальный mempool,
дошла до пиров,
успешно выполнилась
или была финализирована.
Сначала это казалось слишком техническим различием.
Затем я нашёл более странный пограничный случай.
Действительная транзакция с будущим nonce может ждать в prequeue, пока не будет устранён недостающий разрыв nonce.
Поэтому можно получить идеально чистый ответ API, но при этом транзакция всё ещё не находится на том этапе, который, вероятно, вас интересует.
Эта часть меня беспокоила.
Много инфраструктуры построено вокруг очень человеческого обходного пути:
API сказал «да» → задача сделана.
Руководство по интеграции обмена Dusk предполагает обратное.
Вывод не должен считаться завершённым только потому, что endpoint пропагации вернул 202 Accepted. Нужно всё ещё проверять выполнение и финальность.
И если слой транспорта тайм-аутит, более безопасный путь восстановления — заново разослать ту же подписанную транзакцию, а не вслепую создавать другую.
И вот где это перестаёт быть любопытством про HTTP-коды.
Если биржа или кошелёк путает принятие на уровне транспорта с завершённостью в реестре, крошечная ошибка интеграции может превратиться в проблему учёта.
Возможно, я слишком много думаю о скучном ответе API ночью.
Но мне кажется, полезное различие простое:
Успех транспорта — не успех реестра.
API может сказать «да» ещё до того, как это сделает цепочка.
Мне пришлось перечитать это дважды, потому что HTTP 202 Accepted обычно заставляет мозг расслабиться.
Но на Dusk, вероятно, не стоит.
Когда /transactions/propagate возвращает 202 Accepted, узел принял транзакцию для маршрутизации.
Одного этого недостаточно, чтобы доказать, что транзакция:
попала в реальный mempool,
дошла до пиров,
успешно выполнилась
или была финализирована.
Сначала это казалось слишком техническим различием.
Затем я нашёл более странный пограничный случай.
Действительная транзакция с будущим nonce может ждать в prequeue, пока не будет устранён недостающий разрыв nonce.
Поэтому можно получить идеально чистый ответ API, но при этом транзакция всё ещё не находится на том этапе, который, вероятно, вас интересует.
Эта часть меня беспокоила.
Много инфраструктуры построено вокруг очень человеческого обходного пути:
API сказал «да» → задача сделана.
Руководство по интеграции обмена Dusk предполагает обратное.
Вывод не должен считаться завершённым только потому, что endpoint пропагации вернул 202 Accepted. Нужно всё ещё проверять выполнение и финальность.
И если слой транспорта тайм-аутит, более безопасный путь восстановления — заново разослать ту же подписанную транзакцию, а не вслепую создавать другую.
И вот где это перестаёт быть любопытством про HTTP-коды.
Если биржа или кошелёк путает принятие на уровне транспорта с завершённостью в реестре, крошечная ошибка интеграции может превратиться в проблему учёта.
Возможно, я слишком много думаю о скучном ответе API ночью.
Но мне кажется, полезное различие простое:
Успех транспорта — не успех реестра.
API может сказать «да» ещё до того, как это сделает цепочка.
