You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Apr 11, 2023. It is now read-only.
Repository navigation
This repository was archived by the owner on Apr 11, 2023. It is now read-only.
Osmosis trades fail if one is started while the previous tx is still in mempool #995
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:
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
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.
Activity
kaladinlight commentedon Aug 26, 2022
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
elmutt commentedon Aug 29, 2022
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.