Skip to content
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

Closed
theotniel opened this issue Jun 12, 2018 · 4 comments
Closed
Assignees

Comments

@theotniel
Copy link
Contributor

theotniel commented Jun 12, 2018

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 by sync-ib nodes:
screenshot from 2018-06-12 11-37-19

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
screenshot from 2018-06-12 10-58-59

screenshot from 2018-06-12 10-59-01

L.E: Kernel version is: v0.2.7.1bbeec1

@AionJayT
Copy link
Collaborator

fixed in 9551b20

@AionJayT AionJayT self-assigned this Jun 14, 2018
@theotniel
Copy link
Contributor Author

@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.
However, when the node was effectively synced, we were getting rather weirn numbers:

  1. If the node had been running for a while, the chain best is a significantly larger number than the network best:
    screenshot from 2018-06-18 11-09-14

  2. If the node was just started, the numbers stay in a range 1-2 from each other but they drift apart after a while, with the chain best becoming larger than the network best:
    screenshot from 2018-06-18 11-10-30

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)

@AionJayT
Copy link
Collaborator

@centrys-otniel this should be the kernel issues. The syncMgr maybe doesn't update the status on-time
I will take a look.

@AionJayT
Copy link
Collaborator

AionJayT commented Jul 6, 2018

fix the issue in the kernel PR.
the kernel binary will publish in the mid of July
aionnetwork/aion#544

@AionJayT AionJayT closed this as completed Sep 6, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants