(Planned in the second wave)
In our web3-compatible blockchain interface, there is a method we use to submit a batch of tx receipts.
The problem is that when we get the response we don't make sure if we understand in what order the provided values are, to hopefully match exactly the order of the tx hashes (from txs whose receipts we query) when, at the beginning, we'd fed this method with args. We don't care according the code, but my guts say we should at least a little bit.
The todo!()s identify places where we might like to have additional processing code. However, it could be treated in various ways.
fn process_transaction_receipts(
&self,
tx_hashes: Vec<TxHashByTable>,
) -> Box<dyn Future<Item = Vec<TxReceiptResult>, Error = BlockchainInterfaceError>>
{
Box::new(
self.lower_interface()
.get_transaction_receipt_in_batch(Self::collect_plain_hashes(&tx_hashes))
.map_err(move |e| e)
.and_then(move |batch_response| {
if batch_response.len() != tx_hashes.len() {
todo!("return an error?!")
}
Ok(batch_response
.into_iter()
.zip(tx_hashes.into_iter())
.map(|(response, tx_hash)| match response {
Ok(result) => {
match serde_json::from_value::<TransactionReceipt>(result) {
Ok(receipt) => {
if receipt.transaction_hash != tx_hash.plain_hash(){
todo!("do not use or return an error?!")
}
TxReceiptResult(Ok(RetrievedTxStatus::new(
tx_hash,
receipt.into(),
)))
},
Err(e) => {
if e.to_string().contains("invalid type: null") {
TxReceiptResult(Ok(RetrievedTxStatus::new(
tx_hash,
StatusReadFromReceiptCheck::Pending,
)))
} else {
TxReceiptResult(Err(TxReceiptError::new(
tx_hash,
AppRpcWeb3Error::Remote(RemoteError::InvalidResponse(
e.to_string(),
)),
)))
}
}
}
}
Err(e) => TxReceiptResult(Err(TxReceiptError::new(tx_hash, e.into()))),
})
.collect::<Vec<TxReceiptResult>>())
}),
)
}
(Planned in the second wave)
In our web3-compatible blockchain interface, there is a method we use to submit a batch of tx receipts.
The problem is that when we get the response we don't make sure if we understand in what order the provided values are, to hopefully match exactly the order of the tx hashes (from txs whose receipts we query) when, at the beginning, we'd fed this method with args. We don't care according the code, but my guts say we should at least a little bit.
The todo!()s identify places where we might like to have additional processing code. However, it could be treated in various ways.