Hi!
while using rosetta-cli check:data --configuration-file ./rosetta-config --end 1000 , I’m getting the following message:
[STATS] Blocks: 1001 (Orphaned: 0) Transactions: 111487 Operations: 222974 Reconciliations: 0 (Inactive: 0)
Check succeeded, however, no reconciliations were performed!
I would like to get those reconciliation checks done, I currently have "reconciliation_disabled": false on my config file, is that correct ?
Thanks!
If you wish to reconcile balances before the rosetta-cli reaches tip (which I am assuming is the case), you must support historical_balance_lookup. Unfortunately, there is no way to reconcile (compare computed balance with the balance returned via the /account/balance endpoint) at early blocks if we can’t fetch the balance at those blocks (we can only get the balance at the current block).
If you wait until the rosetta-cli syncs to tip (when historical_balance_lookup=false), it will automatically begin performing reconciliations when it determines it is possible. If you are curious how it does this, take a look at the reconciler package!
Great, thanks @patrick.ogrady
The flag --end doesn’t work as a “tip”, right ?
The blockchain I’m now using takes about 2s for each /block call, and it has more than 170k blocks, so it’s going to take a while to reach the reconciliations stage 
No it does not 
. We are actively working on adding more sophisticated end conditions (like reaching tip, performing some number of reconciliations, etc.). We are tracking it with an issue in rosetta-cli (hoping to add support within the week).
Have you tried increasing the block_concurrency parameter in your config file? When doing my own testing, I usually ramp this up to 32 or even 64. 
Great, will try that!
Hi @patrick.ogrady,
I would like to run check with reconciliation enable
Must I run rosetta-cli from genesis block 0 ?
Does start_index work with reconciliation_disable: false ?
Great question!
This will work as long as your implementation supports historical balance lookup. When a new account is seen, we will attempt to fetch its balance at the parent block if we haven’t seen it yet and can only do that if we can access the balance at any previous block.
Just a warning that doing this will lead to a tad bit slower sync (because of the extra fetches) but shouldn’t be too bad!
look like it doesn’t work @patrick.ogrady
"data": {
"active_reconciliation_concurrency": 0,
"inactive_reconciliation_concurrency": 0,
"inactive_reconciliation_frequency": 0,
"log_blocks": false,
"log_transactions": false,
"log_balance_changes": false,
"log_reconciliations": false,
"ignore_reconciliation_error": false,
"exempt_accounts": "",
"interesting_accounts": "",
"reconciliation_disabled": false,
"inactive_discrepency_search_disabled": false,
"balance_tracking_disabled": false,
"coin_tracking_disabled": true,
"results_output_file": "",
"start_index": 190,
"bootstrap_balances": "bootstrap_balances.json"
}
In my test,
The chain had a reward operation at block 180 but start_index=190, so
computed_balance = initial_balance in bootstrap
while live_balance = initial _balance + miner reward at block 180
-> reconciliation failure
Could you remove the bootstrapping of balances (when starting from a non-genesis index)? Existing accounts (created during bootstrapping) will not have their balances “pre-fetched” (the feature I discussed earlier).
If I remove "bootstrap_balances": "bootstrap_balances.json"
looks like all accounts start with zero balance while some accounts have balance from genesis
Therefore, reconciliation failed at start_index
Command Failed: reconciliation failure: active reconciliation error for 0xa8D38FB29CDA4Ca011b430a680886fB4CA7F3043 at 183 (computed: 0TOMO, live: 55000000000000000000000000TOMO)
You’ll also need to delete the data directory you were using from the last time you synced (not sure if you did that). Reminder: this only works if historical balance lookup is enabled.
@patrick.ogrady, Thank you so much for hint me potential root cause.
I found my bad with wrong implementation in Historical Balance Lookup
I enabled historical balance lookup in my implementation like this
https://github.com/coinbase/rosetta-ethereum/blob/master/cmd/run.go#L69 -> set this value true
Try to send manual request to account/balance endpoint with specified block number, it works
So I believe historical balance lookup works correctly
But reconciliation still failed
start_index: 192
I put some logs in getBalance functions. When I run cli check, I didn’t see any call to get balance of the previous block like 191, 190, 189, 188
So I wonder if I miss anything in cli config ?
"data": {
"active_reconciliation_concurrency": 0,
"inactive_reconciliation_concurrency": 0,
"inactive_reconciliation_frequency": 0,
"log_blocks": false,
"log_transactions": false,
"log_balance_changes": false,
"log_reconciliations": false,
"ignore_reconciliation_error": false,
"exempt_accounts": "",
"interesting_accounts": "",
"reconciliation_disabled": false,
"inactive_discrepency_search_disabled": false,
"balance_tracking_disabled": false,
"coin_tracking_disabled": true,
"results_output_file": "",
"start_index": 192
}
Could you share the response from /network/options? You need to make sure you set NetworkOptionsResponse.allow.historical_balance_lookup = true.
You can find an example of what this looks like here:
If you don’t populate this, rosetta-cli won’t know it can perform historical lookups!
Let me know if you have any questions or think additional documentation should be added to make this clearer!