embark/packages/embark-blockchain-connector/src/fundAccount.js

78 lines
1.9 KiB
JavaScript
Raw Normal View History

const async = require('async');
const TARGET = 0x7FFFFFFFFFFFFFFF;
const ALREADY_FUNDED = 'alreadyFunded';
function fundAccount(web3, accountAddress, hexBalance, callback) {
if (!hexBalance) {
hexBalance = TARGET;
}
fix(@embark/core): fix to allow large ether values Specifying large ether values in the configs was causing embark to crash as javascript could not handle the large integer after the value was converted to wei. The fix involves converting all values to BigNumbers and then comparing and adding/subtracting BigNumbers from that point forward. There are two specific components that this affected: `config/contracts > accounts > balance` and `config/blockchain > account > balance`. The contracts config is used to fund accounts for contract deployment while the blockchain config is used for dev_funds accounts. JSON.stringify unknown log messages Add a unit test in the test app that sets a large ether value in the config before contract deployment and ensures the account balance is the value specified in the config. Prior to this commit, if subsequent unit tests contained different account configurations, the blockchain VM was essentially reset, however EmbarkJS was hanging on to the old providers it used from the previous configuation. In addition, there is a limitation with `embark.registerActionForEvent` in that the action will be persisted across configuration changes. In our case, once the configuration was updated in a subsequent unit test, the directive subdomains would be attempted to be registered in ENS using the old configuration. This commit does two things: 1) It resets the EmbarkJS.Blockchain and EmbarkJS.Names providers to the new chain configuration 2) Update to the ENS directives that prevents attempts at registered configured subdomains for previous configurations.
2018-11-29 07:12:00 +00:00
const targetBalance = web3.utils.toBN(hexBalance);
let accountBalance;
let coinbaseAddress;
let lastNonce;
let gasPrice;
async.waterfall([
function getAccountBalance(next) {
web3.eth.getBalance(accountAddress, (err, balance) => {
if (err) {
return next(err);
}
fix(@embark/core): fix to allow large ether values Specifying large ether values in the configs was causing embark to crash as javascript could not handle the large integer after the value was converted to wei. The fix involves converting all values to BigNumbers and then comparing and adding/subtracting BigNumbers from that point forward. There are two specific components that this affected: `config/contracts > accounts > balance` and `config/blockchain > account > balance`. The contracts config is used to fund accounts for contract deployment while the blockchain config is used for dev_funds accounts. JSON.stringify unknown log messages Add a unit test in the test app that sets a large ether value in the config before contract deployment and ensures the account balance is the value specified in the config. Prior to this commit, if subsequent unit tests contained different account configurations, the blockchain VM was essentially reset, however EmbarkJS was hanging on to the old providers it used from the previous configuation. In addition, there is a limitation with `embark.registerActionForEvent` in that the action will be persisted across configuration changes. In our case, once the configuration was updated in a subsequent unit test, the directive subdomains would be attempted to be registered in ENS using the old configuration. This commit does two things: 1) It resets the EmbarkJS.Blockchain and EmbarkJS.Names providers to the new chain configuration 2) Update to the ENS directives that prevents attempts at registered configured subdomains for previous configurations.
2018-11-29 07:12:00 +00:00
balance = web3.utils.toBN(balance);
if (balance.gte(targetBalance)) {
return next(ALREADY_FUNDED);
}
accountBalance = balance;
next();
});
},
function getNeededParams(next) {
async.parallel([
function getCoinbaseAddress(paraCb) {
web3.eth.getCoinbase()
.then((address) => {
coinbaseAddress = address;
paraCb();
}).catch(paraCb);
},
function getGasPrice(paraCb) {
web3.eth.getGasPrice((err, price) => {
if (err) {
return paraCb(err);
}
gasPrice = price;
paraCb();
});
}
], (err, _result) => {
next(err);
});
},
function getNonce(next) {
web3.eth.getTransactionCount(coinbaseAddress, (err, nonce) => {
if (err) {
return next(err);
}
lastNonce = nonce;
next();
});
},
function sendTransaction(next) {
web3.eth.sendTransaction({
from: coinbaseAddress,
to: accountAddress,
fix(@embark/core): fix to allow large ether values Specifying large ether values in the configs was causing embark to crash as javascript could not handle the large integer after the value was converted to wei. The fix involves converting all values to BigNumbers and then comparing and adding/subtracting BigNumbers from that point forward. There are two specific components that this affected: `config/contracts > accounts > balance` and `config/blockchain > account > balance`. The contracts config is used to fund accounts for contract deployment while the blockchain config is used for dev_funds accounts. JSON.stringify unknown log messages Add a unit test in the test app that sets a large ether value in the config before contract deployment and ensures the account balance is the value specified in the config. Prior to this commit, if subsequent unit tests contained different account configurations, the blockchain VM was essentially reset, however EmbarkJS was hanging on to the old providers it used from the previous configuation. In addition, there is a limitation with `embark.registerActionForEvent` in that the action will be persisted across configuration changes. In our case, once the configuration was updated in a subsequent unit test, the directive subdomains would be attempted to be registered in ENS using the old configuration. This commit does two things: 1) It resets the EmbarkJS.Blockchain and EmbarkJS.Names providers to the new chain configuration 2) Update to the ENS directives that prevents attempts at registered configured subdomains for previous configurations.
2018-11-29 07:12:00 +00:00
value: targetBalance.sub(accountBalance),
gasPrice: gasPrice,
nonce: lastNonce
}, next);
}
], (err) => {
if (err && err !== ALREADY_FUNDED) {
return callback(err);
}
callback();
});
}
module.exports = fundAccount;