After chain catch up I see no "Imported new chain segment" in logs

[sammy007]

v1.3.3.

I did some maintenance and Bor was stopped for a day. After start and successful catch up I am getting ONLY Got new milestone from heimdall and Got new checkpoint from heimdall. I restarted Bor and I finally see Imported new chain segment. This should not occur after chain catch up.

[sammy007]

Another node after that same procedure (1.3.4-beta2):

--data '{"jsonrpc":"2.0","method":"eth_syncing","params":[],"id":1}'

{"jsonrpc":"2.0","id":67,"result":false}

INFO [06-25|03:40:17.961] Whitelisting milestone deferred          err="chain out of sync"
INFO [06-25|03:40:29.961] Whitelisting milestone deferred          err="chain out of sync"
INFO [06-25|03:40:41.959] Whitelisting milestone deferred          err="chain out of sync"
INFO [06-25|03:40:53.960] Whitelisting milestone deferred          err="chain out of sync"
INFO [06-25|03:41:05.959] Whitelisting milestone deferred          err="chain out of sync"
INFO [06-25|03:41:17.959] Whitelisting milestone deferred          err="chain out of sync"
INFO [06-25|03:41:29.961] Whitelisting milestone deferred          err="chain out of sync"
INFO [06-25|03:41:41.961] Whitelisting milestone deferred          err="chain out of sync"
INFO [06-25|03:41:53.960] Whitelisting milestone deferred          err="chain out of sync"
INFO [06-25|03:42:05.959] Whitelisting milestone deferred          err="chain out of sync"
INFO [06-25|03:42:17.959] Whitelisting milestone deferred          err="chain out of sync"

Peer count is 0x15.

[sammy007]

Whitelisting milestone deferred err="chain out of sync" --data '{"jsonrpc":"2.0","method":"eth_syncing","params":[],"id":1}'

{"jsonrpc":"2.0","id":67,"result":false}

Peer count: 0xe

[sammy007]

Switched back to v1.3.3

unable to handle whitelist milestone err="missing blocks" '{"jsonrpc":"2.0","method":"eth_syncing","params":[],"id":1}'

{"jsonrpc":"2.0","id":67,"result":false}

Broken software.

[sammy007]

Okay, I have deleted /bor/nodes and especially /bor/nodekey. The /bor was a carbon copy of another live node and it seems peers does not like it. Seems finally finished catching up and running fine. As to wrong reporting of eth_syncing, it sucks to see that. The only sense of using it is to check if node is in sync and if it knows that it's not in sync the response must not be false.

[0xtakamaka]

@sammy007 thank you for this!!!! I spent 2 days debugging, you saved me!

[hdiass]

Problem still exists on every bor node. When you guys can fix this issue ?

[cshintov]

Potential fix. https://github.com/maticnetwork/bor/issues/1239#issuecomment-2235835196

[andreclaro]

I'm facing this issue after upgrading to v1.3.4:

bor[2457801]: {"t":"2024-07-29T09:49:20.094714808Z","lvl":"info","msg":"Whitelisting milestone deferred","err":"chain out of sync"}

[oanhle]

@andreclaro try this, i solved it this way: cd /var/lib/bor nano config.toml edit bootnodes file like "bootnodes = ["enode://b8f1cc9c5d4403703fbf377116469667d2b1823c0daf16b7250aa576bacf399e42c3930ccfcb02c5df6879565a2b8931335565f0e8d3f8e72385ecf4a4bf160a@3.36.224.80:30303", "enode://8729e0c825f3d9cad382555f3e46dcff21af323e89025a0e6312df541f4a9e73abfa562d64906f5e59c51fe6f0501b3e61b07979606c56329c020ed739910759@54.194.245.5:30303","enode://a7f59b918fe19b5448b6dfbb35d5096eaffcdf20050f41f442c4a72377f7634da10fe23b1a405f72f6146b3c78738160c98c2c47d60a81e489fa47a50fe8700c@77.172.185.210:30303","enode://dcafedac347b24aea85a4b396511dc7ba4da37cd2ce13de9511aba50879fe04e6e259ce6314ae3376c1e3cc2f1909273781a74e9c386bcec29f5b42d1db0fe14@47.76.152.221:30303"]"

[anshalshukla]

@andreclaro the log you have mentioned is not an issue but tells that the chain is out of sync and should go away as soon as it catches up to the tip.

With recent release we have seen that most of the syncing issues have been resolved, feel free to open the ticket again if that's not the case with you.