DB
нонс разный
вобщем непонятно
если слать и надеяться на лучшее то все быстро
но если вылетит то непонятно что делать
Size: a a a
2021 March 02
N|
ну направление мысли понятно
осталось придумать реализацию
осталось придумать реализацию
N|
просто ветвистый код получается
N|
нонс разный
нонс разный а время одно
DB
ну ты их пачкой значит отправлял, или это типа повторная отправка?
N|
ну это примерно так было
я отправил пачку
отправилось не все
потом я те что неотправились снова отправляю
но где то там на серверах те неушедшие транзакции висели
и видимо попали в один блок сор следущей
я отправил пачку
отправилось не все
потом я те что неотправились снова отправляю
но где то там на серверах те неушедшие транзакции висели
и видимо попали в один блок сор следущей
DB
вообще есть идея как сделать проще. через
fetch-history, ты получаешь через секунд 10 список последних транзакций, ищешь среди них те которые проверяешь и находишь откуда начался косяк, в транзакции там указывается nonce, собственно от него и начинаешь выдавать недостающиеDB
это кстати я думаю верный способ)
DB
а все что выше про вычитание забудь как страшный сон
DB
тогда дублей не произойдет
N|
учту этот вариант тоже когда буду делать проверку )
спасибо за идеи
спасибо за идеи
N|
вообще есть идея как сделать проще. через
fetch-history, ты получаешь через секунд 10 список последних транзакций, ищешь среди них те которые проверяешь и находишь откуда начался косяк, в транзакции там указывается nonce, собственно от него и начинаешь выдавать недостающиееще в этом варианте есть такая проблема
в процессе раздачи кто то может послать транзакцию делегирования например
и нонс собьется
в процессе раздачи кто то может послать транзакцию делегирования например
и нонс собьется
DB
не, этоже не твой нонс
DB
нонс это отправленные тобой
DB
считай каунтспент, чужие нонс тебе не нужны
DB
смотри from = свой адрес
DB
и среди них ищи транзакцию
N|
nonce = count_spent + 1
DB
нонс это и есть каунтспент на момент отправки. следующий нонс будет +1 для новой транзакции