You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I was syncing a new node from scratch, full node. And noticed that during sync blocks are being discarded because they are too far ahead. This makes sense when syncing a new node, and I have seen this behavior before. Which raises the question, is this a explicit design decision or could this be optimized a bit further?
Expected behavior
A new node syncs up with the chain relatively quickly.
Actual behavior
Blocks are being discarded because they are too far ahead.
Mar 25 18:10:46 vps-a60b17b1 nimiq-client[2603706]: 2024-03-25T18:10:46.491123320Z INFO nimiq_client | Consensus: lost - Head: #16378724:MA:eb4e9f439b - Peers: 21 consensus_established=false block_number=16378724 num_peers=21
Mar 25 18:10:47 vps-a60b17b1 nimiq-client[2603706]: 2024-03-25T18:10:47.131930170Z WARN block_queue | Discarding block #19313160:MI:6b078dc74a - too far ahead (max 16389644)
Mar 25 18:10:48 vps-a60b17b1 nimiq-client[2603706]: 2024-03-25T18:10:48.131304611Z WARN block_queue | Discarding block #19313161:MI:84993f8e57 - too far ahead (max 16389644)
Mar 25 18:10:49 vps-a60b17b1 nimiq-client[2603706]: 2024-03-25T18:10:49.088974382Z WARN block_queue | Discarding block #19313162:MI:4a8bcdc208 - too far ahead (max 16389644)
Mar 25 18:10:50 vps-a60b17b1 nimiq-client[2603706]: 2024-03-25T18:10:50.110234655Z WARN block_queue | Discarding block #19313163:MI:0e2d208d9f - too far ahead (max 16389644)
Mar 25 18:10:51 vps-a60b17b1 nimiq-client[2603706]: 2024-03-25T18:10:51.085727334Z WARN block_queue | Discarding block #19313164:MI:c5285cae97 - too far ahead (max 16389644)
Mar 25 18:10:52 vps-a60b17b1 nimiq-client[2603706]: 2024-03-25T18:10:52.072425313Z WARN block_queue | Discarding block #19313165:MI:49b2c2b729 - too far ahead (max 16389644)
Mar 25 18:10:53 vps-a60b17b1 nimiq-client[2603706]: 2024-03-25T18:10:53.191180464Z WARN block_queue | Discarding block #19313166:MI:541722688c - too far ahead (max 16389644)
Mar 25 18:10:54 vps-a60b17b1 nimiq-client[2603706]: 2024-03-25T18:10:54.184988818Z WARN block_queue | Discarding block #19313167:MI:afdd39e680 - too far ahead (max 16389644)
Mar 25 18:10:55 vps-a60b17b1 nimiq-client[2603706]: 2024-03-25T18:10:55.159840395Z WARN block_queue | Discarding block #19313168:MI:f6167fdda9 - too far ahead (max 16389644)
Mar 25 18:10:56 vps-a60b17b1 nimiq-client[2603706]: 2024-03-25T18:10:56.110537415Z WARN block_queue | Discarding block #19313169:MI:bc5abb5e0f - too far ahead (max 16389644)
This keeps going on for a long time and the head block of my node doesn't progress at all, but stays at 16389644
The text was updated successfully, but these errors were encountered:
General information
Bug report
I was syncing a new node from scratch, full node. And noticed that during sync blocks are being discarded because they are too far ahead. This makes sense when syncing a new node, and I have seen this behavior before. Which raises the question, is this a explicit design decision or could this be optimized a bit further?
Expected behavior
A new node syncs up with the chain relatively quickly.
Actual behavior
Blocks are being discarded because they are too far ahead.
This keeps going on for a long time and the head block of my node doesn't progress at all, but stays at
16389644
The text was updated successfully, but these errors were encountered: