Open 0xean opened 1 month ago
regression of a previous fix
I've made an improvement to streaming here: https://github.com/shapeshift/web/pull/7573
But for this ticket specifically I've been unable to replicate. It seems streaming swaps in the order of 6 figures USD complete within one swap and block (even when I override the memo before broadcasting - there is possibly a minimum on the THORChain side?).
For example, I overrode this small swap with 3/6 and it still completed immediately: https://viewblock.io/thorchain/tx/ef485bef45ca5e0cf471b0d7dff8ef8279b0e8e300077d843854d9513a8f8a79
It's possible I need significantly more funds to replicate and fix this issue.
@gomesalexandre ser you might have further thoughts on this guy.
I've made an improvement to streaming here: #7573
But for this ticket specifically I've been unable to replicate. It seems streaming swaps in the order of 6 figures USD complete within one swap and block (even when I override the memo before broadcasting - there is possibly a minimum on the THORChain side?).
For example, I overrode this small swap with 3/6 and it still completed immediately: viewblock.io/thorchain/tx/ef485bef45ca5e0cf471b0d7dff8ef8279b0e8e300077d843854d9513a8f8a79
It's possible I need significantly more funds to replicate and fix this issue.
@gomesalexandre ser you might have further thoughts on this guy.
@0xApotheosis I noticed this as well with streaming swaps - think the consensus is indeed small streaming swaps usually do not trigger an actual streaming swap (i.e many intermediary swaps) with 0 (auto) quantity, though overriding it should theoretically work. @0xean do you have the Txid handy for this swap so we can try and replicate the memo here?
Bad bot GitHub, #7573 didn't close this
FYI @0xApotheosis while this is super hard to tackle without being able to repro actual streaming swaps, the root cause here is the same as https://github.com/shapeshift/web/pull/7506: we don't have any fancy logic (well, we actually do, see below) to mutate Txids on the fly and use the regular swapper execution architecture to determine completion: when the initiating Txid is confirmed, we assume the swap as complete (ish, we actually do have some kind of fancy logic which is not working here, see getLatestThorTxStatusMessage
)
The way this was solved for SAFE Txs was through checkTradeStatus
by mutating Txids on the fly: originally mutating the Tx hash (the initiating Tx) to be a pending Tx (vs. confirmed as it would currently be), and then returning a different Txid (the actual on-chain Tx, through SAFE API) once we have it, and then leveraging good ol' evm status detection through checkEvmSwapStatus
.
Think the exact same could be done here, though once again, without actual streaming swaps, that would be hard to verify working, but if anything should not make things worse for regular swaps and may at worse make streaming swaps stuck in pending state:
We could introspect both the /thorchain/tx/status
and the /thorchain/swap/streaming
endpoints and use the intersection of quantity
(or lack thereof) and swap_finalised
/ outbound_signed
to determine completion.
Actually rubber ducking myself here while writing this, getLatestThorTxStatusMessage
already does something similar for status polling and could potentially be accomodated for that use-case.
I thought we had a ticket for this but not sure where
A streaming swap shows completed after the initial TX is confirmed even though it is still streaming:
AC