Open 314159265359879 opened 1 year ago
The user experienced this again. Console log indicates err 400
SP3GCSJH3J5TVJEJD1FVXK44GFXR8633AJJ5E5BEY
Oddly the user send a transaction first that went through alright, with the correct nonce (746 now) and then when trying to send the next one the error occurred and the wallet set a nonce of 738... leading to the incorrect nonce error.
The user mentioned that nonce error has happened for them also without a stuck transaction sometimes. But most of the times it eventually worked after a few tries. Not now with a stuck one. And no clue why they get stuck in the meantime.
The new ones do appear in the activities tab.
I suspect the implementation of this new API functionality may help in this case and other nonce ones we see generally these days? https://github.com/hirosystems/desktop-wallet/issues/1193#issuecomment-1573885590 cc @fbwoolf
(Note how the above issue was filed for the desktop wallet, though here we'd need to apply it for the extension one as well)
I suspect the implementation of this new API functionality may help in this case and other nonce ones we see generally these days? hirosystems/desktop-wallet#1193 (comment) cc @fbwoolf
(Note how the above issue was filed for the desktop wallet, though here we'd need to apply it for the extension one as well)
Hi @markmhx, I think you are referring to a new API for nonces. Is that right? would you mind linking to it.
In this case and with the desktop wallet issue it looks a lot like NO API is reached and that is causing wrong nonces to be set. The wallet should have a fallback option or warn users (so they can manually check it)?
Scenario
Would this only occur if the nextNonce API is unreachable? (asking the user to share console log, next time they see this).
In my experience the wallet will set the nonce correctly even with an unprocessable transaction in the mempool. Are there any recent changes to the wallet or API that could have caused this?