fix: wait synced requires initial connected peer

[mmrrnn]

#1348

Description

Finish node syncing not only when initial_sync_achieved but also initial_connected_peers

Motivation and Context

Sometimes app finishes node syncing when no initial_connected_peers. It leads to a situation where we begin mining on an outdated chain. This chain is synced later, once a connection to a peer is finally established.

How Has This Been Tested?

App sometimes doesn't connect to any peer and receives initial_sync_achieved as true. Not sure how to reproduce it on demand.

[brianp]

This branch looks good, but when the base node suffers any issues users get stuck on setup screen now. Which is correct behaviour, but we need some base node fixes in place before we apply this, as it will make ti seem more broken, as the errors were hidden before and seemingly all was working.

[brianp]

Even with the updated base node. This branch won't finalize syncing and move away from the setup screen. Base node logs say the chain is up to date but we remain stuck on setup screen.

If I sync from main and then checkout this branch, with the updated base node I can't seem to find peers. Base node log will again confirm I do have peers and am connected. But the setup screen is not updated, and I never progress forward.

[mmrrnn]

I wanted to prevent from false positive initial_sync_achieved when no connections. Seems working better now, I'll test it further later today. I think the core problem is somewhere in the node itself:

=== tip_res: TipInfoResponse { metadata: Some(MetaData { best_block_height: 62287, best_block_hash: [169, 209, 208, 1, 18, 31, 35, 144, 103, 143, 95, 35, 133, 90, 144, 2, 218, 226, 233, 58, 64, 141, 1, 89, 153, 15, 123, 211, 120, 162, 96, 209], accumulated_difficulty: [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 3, 118, 211, 142, 14, 220, 39, 52, 195, 244, 70, 192, 108, 136], pruned_height: 0, timestamp: 1733631880 }), initial_sync_achieved: false, base_node_state: Listening, failed_checkpoints: false }
=== sync_progress: SyncProgressResponse { tip_height: 0, local_height: 0, state: Startup, short_desc: "Waiting for peer data: 0/3", initial_connected_peers: 0 }
=== tip: Response { metadata: MetadataMap { headers: {"content-type": "application/grpc", "date": "Wed, 08 Jan 2025 09:48:44 GMT", "grpc-status": "0"} }, message: TipInfoResponse { metadata: Some(MetaData { best_block_height: 62287, best_block_hash: [169, 209, 208, 1, 18, 31, 35, 144, 103, 143, 95, 35, 133, 90, 144, 2, 218, 226, 233, 58, 64, 141, 1, 89, 153, 15, 123, 211, 120, 162, 96, 209], accumulated_difficulty: [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 3, 118, 211, 142, 14, 220, 39, 52, 195, 244, 70, 192, 108, 136], pruned_height: 0, timestamp: 1733631880 }), initial_sync_achieved: true, base_node_state: Listening, failed_checkpoints: false }, extensions: Extensions }
=== tip_res: TipInfoResponse { metadata: Some(MetaData { best_block_height: 62287, best_block_hash: [169, 209, 208, 1, 18, 31, 35, 144, 103, 143, 95, 35, 133, 90, 144, 2, 218, 226, 233, 58, 64, 141, 1, 89, 153, 15, 123, 211, 120, 162, 96, 209], accumulated_difficulty: [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 3, 118, 211, 142, 14, 220, 39, 52, 195, 244, 70, 192, 108, 136], pruned_height: 0, timestamp: 1733631880 }), initial_sync_achieved: true, base_node_state: Listening, failed_checkpoints: false }
=== sync_progress: SyncProgressResponse { tip_height: 0, local_height: 0, state: Done, short_desc: "Listening", initial_connected_peers: 0 }
=== initial_sync_achieved

[brianp]

Tested. It does seem to work better now. The one thing I don't like is that we still say we're waiting for 0/3 peers, then we get 1/3 peers and we move on.

Lets change the text to align with what we're doing.

Connecting to network peers... {{initial_connected_peers}} connected

Edit: Actually I am still running into the problem of not making it passed the setup screen on both sync peers, and block sync.

It only happens to me on this branch 🫣

[mmrrnn]

Coverted it to draft. We need to investigate it in the base node repo. We shouldn't receive initial_sync_achieved as true, when no connected peers