Osmosis trades fail if one is started while the previous tx is still in mempool
Overview
When swapping using osmosis osmo -> atom and a second trade is quickly initiazted before the first trade clears the mempool we get the following error:
Error [Kind: Error] {"message":"failed to broadcast transaction: codespace: sdk, code: 32, description: incorrect account sequence"}
References and additional details
https://github.com/shapeshift/web/pull/2570#pullrequestreview-1087426096
Acceptance Criteria
Consult with @shapeshift/product to determine an acceptable solution to this problem --- Perhaps an error toast if getting the correct sequence number is not reliably accurate or reasonable
Need By Date
No response
Screenshots/Mockups
No response
Estimated effort
No response
This is another shortcoming of the tendermint protocol. None of the state updates until the transaction is observed in a block and there is no functionality to query pending state like you would think to do on any other chain. There is also no websocket subscription for unconfirmed transactions, however there is a rest endpoint that can be polled to try and keep an accurate state of mempool.
If we were to build this out in unchained, we could add some sequence number logic that would increment the sequence number returned by the node by the number of current unconfirmed transactions. There are all sorts of edge cases obviously that would need to be explored, but there would be a some mitigation factors that could improve this current error condition.
The other option would be a client side pending tx cache that could be managed to show pending txs until unchained confirms and increment the sequence accordingly. This would obviously not catch or know about any external pending transactions, but that would be an even more extreme edge case
I agree there are lots of edge cases and no straightforward solution. IMO its could be fine as-is because they will get an error modal on their trade attempt but then just try again and it will probably work by then.