Closed immartian closed 7 years ago
after initial investigation, there's no problem with Parity block tracing with it's RPC interface. The lost information can be fetched anytime. The problem may happen during the writing process to DB, which may skip some asynchronous exceptions. Will dig into this direction.
Hi @phiferd , can you help examine 2 funcs below to see how to optimize for asynchronous between RPC call and DB writing?
function 1: fetching internal tx from blockchain with Parity instrumental support:
function grabInternalTxs(web3, blockHashOrNumber) {
var fromBlock = web3.toHex(web3.eth.getBlock(blockHashOrNumber).number);
var toBlock = fromBlock;
var id = web3.eth.getBlock(blockHashOrNumber).number;
var post_data = '{ \
"jsonrpc":"2.0", \
"method":"trace_filter", \
"params":[{"fromBlock":"' + fromBlock + '"}], \
"id":' + id + '}';
var post_options = {
host: 'localhost',
port: '8545',
path: '/',
method: 'POST',
headers: { "Content-Type": "application/json" }
};
var post_req = http.request(post_options, function(res) {
res.setEncoding('utf8');
var data;
res.on('data', function (chunk) {
if (chunk)
data = chunk;
});
res.on('end', function() {
try {
var jdata = JSON.parse(data);
} catch (e) {
console.error(e);
batchSize = 10;
if (batchSize > 1) {
for (var b=0; b<batchSize; b++) {
grabInternalTxs(web3, blockHashOrNumber+b, 1);
}
} else {
console.error(post_data);
}
return
}
console.log("\n Internal tx: " + data);
for (d in jdata.result) {
var j = jdata.result[d];
if (j.action.call)
j.action = j.action.call;
else if (j.action.create)
j.action = j.action.create;
else if (j.action.suicide)
j.action = j.action.suicide;
if (j.action.callType)
j.action.callType = Object.keys(j.action.callType)[0]
if (j.result.call)
j.result = j.result.call;
else if (j.result.create)
j.result = j.result.create;
else if (j.result.suicide)
j.result = j.result.suicide;
if (j.action.gas)
j.action.gas = web3.toDecimal(j.action.gas);
if (j.result.gasUsed)
j.result.gasUsed = web3.toDecimal(j.result.gasUsed);
j.subtraces = web3.toDecimal(j.subtraces);
j.transactionPosition = web3.toDecimal(j.transactionPosition);
j.blockNumber = web3.toDecimal(j.blockNumber);
j.timestamp = web3.eth.getBlock(blockHashOrNumber).timestamp;
writeTxToDB(j);
}
});
});
post_req.write(post_data);
post_req.end();
}
func 2: writing to DB one by one once received the internal tx from current block. I guess missing data happened in this moment:
var writeTxToDB = function(txData) {
return InternalTx.findOneAndUpdate({"transactionHash": txData.transactionHash}, txData, {upsert: true}, function( err, tx ){
if ( typeof err !== 'undefined' && err ) {
if (err.code == 11000) {
console.log('Skip: Duplicate key ' +
txData.number.toString() + ': ' +
err);
} else {
console.log('Error: Aborted due to error: ' +
err);
process.exit(9);
}
} else {
console.log('DB successfully written for tx ' +
txData.transactionHash.toString() + " and tx:" +txData.transactionHash);
}
});
}
Please help test this resolution and confirm it's acceptability, @phiferd . The bug is not about async calls, but a DB query and update issue with new internal tx overriding the previous internal tx with same hash value. A low level error.
I setup a contract that had two recipients, each with one share. However, orbiter shows 4 internal transactions, each for 0.5mc:
http://orbiter.musicoin.org/tx/0xdb0f8041f164d9fa9b18e80cc91f3d8108e43cb7e1ca54254cc83faea59bcee5
contract address: 0x4b0cc19354821b171ce997f2ad5e5834c8b4e6be
somehow the DB fetching duplicated, I will look into this. Don't worry about your part, it's presentation issue.
@phiferd please check if new tx still cause this issue, as I fixed bug but not sure if fully solved. Old tx can be ignored as DB it's written already.
"I set it up to send my account 0.1 mc as a fixed payment, then the remainder split equally between my (test) profile, your profile, and brian's profile. Brian's balance shows as "117.3" musicoin, yours shows as 23.3, and mine shows as 544.4 (since I got an extra 0.1). So, I think it's working, but orbiter might be missing some details", via @phiferd
http://orbiter.musicoin.org/tx/0x9d158e105220544229a23c953793ee2b2e14cc61367602691363bd137609c9fe