-
Notifications
You must be signed in to change notification settings - Fork 16
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix: DOT swap output less than existential deposit #4062
Conversation
PRO-814 Handle egress below existential deposit
It seems like we still don't completely handle this case. AFAIK we use force transfer to ensure the legitimate transfers go through, even if one of them cannot because it's below the ED. However, it seems we're still expecting to witness the success of the egress, which of course, cannot occur. So we will still see a broadcast aborted, despite the transaction succeeding. alastair saw this on his localnet. |
Codecov Report
@@ Coverage Diff @@
## main #4062 +/- ##
======================================
Coverage 72% 72%
======================================
Files 378 378
Lines 60663 60906 +243
Branches 60663 60906 +243
======================================
+ Hits 43495 43677 +182
- Misses 14904 14964 +60
- Partials 2264 2265 +1
... and 16 files with indirect coverage changes 📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more |
Bouncer will never complete because of the test I just added. |
9d7b5cf
to
a59c65c
Compare
a59c65c
to
6e4dd8b
Compare
bda8115
to
ef4a68a
Compare
0c7fd7c
to
44a3b3e
Compare
44a3b3e
to
f8b2d2b
Compare
PRO-871 Fix Polkadot broadcast success witnessing
ProblemWe can currently ignore polkadot broadcast successes if they don't emit a Transfer event. If we make a Current code break downThe current dot witnessing code collects extrinsic indices, which are the extrinsic indices of that block, which produced events that are relevant to us. In the
This if statement checks:
SolutionFor both of these we could instead use the Since all transactions we create are via the proxy, and we get a For the broadcast to be registered as success, we must submit the To test this works, of course all the current bouncer tests should work, and the test in PRO-814 should pass too. That PR can be rebased onto this one in order to test it (CC: marcello - whoever picks this up might take over that branch). Alternative Solutions ConsideredUse the list of TxOutIds to filter the extrinsics we are watching, and then filter only the events from these extrinsics. The drawback of this might be that we would not witness events that are triggered independently (for example governance intervention). |
f8b2d2b
to
5c46326
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In the interests of getting this in quickly. I'm happy if the code comments are resolved, and an issue is created about the test changes
@@ -2,6 +2,7 @@ set -e | |||
./commands/observe_block.ts 5 | |||
./commands/setup_vaults.ts | |||
./commands/setup_swaps.ts | |||
./tests/swap_less_than_existential_deposit_dot.ts |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we should put this as part of the concurrent tests - though, see comment further down
runWithTimeout, | ||
} from '../shared/utils'; | ||
|
||
// This code is duplicated to allow us to specify a specific amount we want to swap |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why is it duplicated? We should factor out the common code here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Because I needed a custom version of the function where I could specify the amount to swap to be sure the output was less than ED, and where the result was determined by observing broadcastSuccess instead of balanceUpdated.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure, it's not all common, but we can factor out the common code, potentially have one function where you can optionally provide an event to observe - haven't thought deeply about how exactly to do it, but it can be done
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
testSwap, performSwap and doPerformSwap have "amount" arguments as of commit 0a09832
amount: string, | ||
balanceIncrease: boolean, | ||
tag = '', | ||
messageMetadata?: CcmDepositMetadata, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this isn't used - deduplicating ofc fixes this too
// and to wait for some specific events | ||
export async function doPerformSwap( | ||
{ sourceAsset, destAsset, destAddress, depositAddress, channelId }: SwapParams, | ||
amount: string, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why string and not number?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
no reason sendERC20 uses string so I just used it as well, we can change it if it makes things more clear
let stopObserving = false; | ||
const observingBadEvents = observeBadEvents(':BroadcastAborted', () => stopObserving); | ||
|
||
// The initial price is 10USDC = 1DOT, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How do we know this? This test is going to be quite flakey with hardcoded values. Ideally we query for the price, and then swap an amount that results in an egress less than the ED.
- This might mean this test can't be part of concurrent tests, but that's fine, would rather have a test that when run individually we know is correct, regardless of the state of the pools at any point in time.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah that's why I put this test as first, because I knew the states of the pool at the beginning of the bouncer (I wasn't sure how to query the prices but maybe it is easy to do so?), and that's also why it wasn't inside the concurrent tests, to be sure that when this is executed the price doesn't suddenly change with another swap.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It might not be easy to do, to check the price, but
a) this is a more useful / robust if we do
b) being able to query for the price will be useful for other more complex / granular swapping tests in the future
c) we can test the relevant price APIs too
so I think it's worth doing, but as mentioned, since I'm unsure how long it'll take I don't mind merging this as is, since the test passed in this order, and then fixing this as part of another issue.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we can query the price of the pool and move this in the concurrent tests then we should also update the observeEvent call to be sure to observe the correct polkadotBrodcast:
I guess we can easily derive the broadcastID knowing the swap channel, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sorry replied before reading your answer, anyway I'll create a linear ticket with all this info so we don't forget if we merge this!
Pull Request
Closes: PRO-871
Issue to resolve comments about the test: PRO-926
Checklist
Please conduct a thorough self-review before opening the PR.
Summary
This test perform 2 swaps:
Dot egress fix: