-
Notifications
You must be signed in to change notification settings - Fork 20
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
getSyncInfo returns suspicios numbers for chainBestBlock - API v0.1.18 #28
Comments
fixed in 9551b20 |
@AionJayT We integrated the new API jar and used it with the 0.2.8 kernel. While the node was syncing we were receiving correct numbers for chain-best and network best.
Also, as you can see, the SyncInfo.syncing boolean is always true. Maybe I'm misunderstanding the meaning it has, but I was expecting this to be false when the node is in a synced state (though this is not really critical for us since we don't rely on it's meaning for now) |
@centrys-otniel this should be the kernel issues. The syncMgr maybe doesn't update the status on-time |
fix the issue in the kernel PR. |
API.getNet().syncInfo()
returns unexpected values - i.e. the reported chainBestBlock is too low.These are the numbers reported by the Java API:
Syncing: true, chainBest: 405384, netBest: 405785
These are the numbers reported by the web3 API:
aion-127.0.0.1:8545> eth.syncing
{ currentBlock: 405785,
highestBlock: 405384,
startingBlock: 400437 }
These are the last lines in the kernel's logs reffering to these node numbers:
18-06-12 09:46:49.482 INFO SYNC [p2p-worker-9]: <import-status: node = c33d5a, hash = be4867, number = 405384, txs = 0, result = IMPORTED_BEST, time elapsed = 1 ms>
18-06-12 10:58:36.047 INFO SYNC [p2p-worker-6]: <import-status: node = c33d22, hash = 4c3620, number = 405785, txs = 0, result = IMPORTED_BEST, time elapsed = 0 ms>
One thing that stood out is that the block reported as the chainBest was the first block processed by a
p2p-worker-*
thread after a batch of blocks processed bysync-ib
nodes:From these numbers I understand that I should not be able to access blocks that have higher numbers than 405384, but fom the Java API I can do that. This suggests that the number reported as
chainBestBlock
is not acurate.You can see below that I can get TransactionDetails from a Block that is higher than the current chainBestBlock:
405384 < 405583
L.E: Kernel version is: v0.2.7.1bbeec1
The text was updated successfully, but these errors were encountered: