Adds 'should reject and not refund a pegout when a contract is trying… #156
Conversation
jeremy-then
force-pushed
the
add-pegout-with-fee-above-value-test
branch
2 times, most recently
from
f39a419 to
f5065f6
Compare
jeremy-then
force-pushed
the
add-pegout-request-from-contract-test
branch
from
11c5790 to
913b560
Compare
lib/contractDeployer.js
Outdated
| const deployCallReleaseBtcContract = async (rskTxHelper) => { | ||
|
|
||
| const address = await rskTxHelper.getClient().eth.personal.newAccount(''); | ||
| await sendFromCow(rskTxHelper, address, Number(btcToWeis(0.5))); |
There was a problem hiding this comment.
I think we have a constant for 0.5 now? maybe I am wrong :)
There was a problem hiding this comment.
Good catch! Updated.
| const TEST_RELEASE_BTC_CONTRACT = '../contracts/CallReleaseBtcContract.sol'; | ||
| const TEST_RELEASE_BTC_CONTRACT_NAME = 'CallReleaseBtcContract'; |
There was a problem hiding this comment.
If this a generic contract deployer perhaps these values should be received by param then?
There was a problem hiding this comment.
The deployCallReleaseBtcContract function is not generic. Look at the name. The idea for this file is that if we need to deploy more specific contracts in the future, we can create a specific function for that.
I did it this way because some contracts might have different parameters and setups.
What do you think? I can make it generic, no problem. Let me know.
There was a problem hiding this comment.
Ok, thanks. I know there are contracts being deployed in other tests, perhaps we could eventually find a way to somehow concentrate that logic here. But out of the scope for now, I'll just create a ticket to analyze further
lib/contractDeployer.js
Outdated
| ); | ||
|
|
||
| return { | ||
| creatorAddress: address, |
There was a problem hiding this comment.
Is this valuable? Shouldn't we simply return the contract address?
There was a problem hiding this comment.
Updated. Returning the contract instance now, since it is needed.
| const pegoutValueInSatoshis = MINIMUM_PEGOUT_AMOUNT_IN_SATOSHIS; | ||
|
|
||
| const { callReleaseBtcContract, creatorAddress } = await deployCallReleaseBtcContract(rskTxHelper); | ||
| const initialRskSenderBalanceInWeisBN = await rskTxHelper.getBalance(creatorAddress); |
There was a problem hiding this comment.
It doesn't have to be the contract creator the one that makes the call right? It can be any address
There was a problem hiding this comment.
Updated. Changed the logic a bit to pass the from address.
|
|
||
| await assert2wpBalancesAfterPegoutFromContract(initial2wpBalances, pegoutValueInSatoshis); | ||
|
|
||
| // The rsk sender should lose the funds since there's no refund when a smart contract is trying to do a pegout |
There was a problem hiding this comment.
Should we also be checking the contract address balance?
jeremy-then
force-pushed
the
add-pegout-request-from-contract-test
branch
from
afaf586 to
9c1d2e2
Compare
… to execute it' test Cherry-picking pegout from contract commit Rebasing
to version 1.1.4
…ted' test. Rebase.
marcos-iov
force-pushed
the
add-pegout-request-from-contract-test
branch
from
9c1d2e2 to
253411e
Compare
|
| const TEST_RELEASE_BTC_CONTRACT = '../contracts/CallReleaseBtcContract.sol'; | ||
| const TEST_RELEASE_BTC_CONTRACT_NAME = 'CallReleaseBtcContract'; |
There was a problem hiding this comment.
Ok, thanks. I know there are contracts being deployed in other tests, perhaps we could eventually find a way to somehow concentrate that logic here. But out of the scope for now, I'll just create a ticket to analyze further
marcos-iov
merged commit b65a362
into
rits-refactors-9-2024-integration
Adds 'should reject and not refund a pegout when a contract is trying to execute it' test