Syncing zebra to kmd times out sometimes

[dimxy]

obtain_tips or extend_tips functions sometimes time out (however syncing may continue).
The reason for that is that zebra sync uses getblocks p2p message but it may repeat calling 'getblocks' for the same block hash. Komodo peer acts differently that zcash on repeated 'getblock' requests and does not respond (if it has put this hash in the known inventory list).
A solution may be to use 'getheaders' that 'getblocks' as 'getheaders' is always responded by komodo nodes. The downside is that getheaders response is bigger in size and could not be parallelised according to zebra doc.

[dimxy]

More info: there are log messages when syncing appears stalled:

2022-10-16T07:28:42.025677Z  INFO dial{candidate=MetaAddr { addr: 15.235.163.41:7770, services: Some(NODE_NETWORK), untrusted_last_seen: Some(DateTime32 { timestamp: 1665864825, calendar: 2022-10-15T20:13:45Z }), last_response: None, last_attempt: Some(Instant { t: 6045764939722615 }), last_failure: None, last_connection_state: AttemptPending }}: tower::timeout::future: dimxyyy tower reached Elapsed timeout for request=OutboundConnectorRequest { addr: 15.235.163.41:7770, connection_tracker: ConnectionTracker }    
2022-10-16T07:28:45.064841Z  INFO dial{candidate=MetaAddr { addr: 3.37.140.228:7770, services: Some(NODE_NETWORK), untrusted_last_seen: Some(DateTime32 { timestamp: 1665862522, calendar: 2022-10-15T19:35:22Z }), last_response: None, last_attempt: Some(Instant { t: 6045767961783743 }), last_failure: None, last_connection_state: AttemptPending }}: tower::timeout::future: dimxyyy tower reached Elapsed timeout for request=OutboundConnectorRequest { addr: 3.37.140.228:7770, connection_tracker: ConnectionTracker }    

[dimxy]

More research results about this issue:
If we change the order of balance calculation (first spent then unspent) the overflow issue still happens in blocks where transactions spend other transactions in the same block:

• if process spent first the balance can go negative
• currently the balance is not initialised to zero for spent utxos (assumed unspent utxos would always init it)
• if if allow balance to be negative and init it with zero by default there is a block 174538 where a very big amount is spent and creates overflow.

My suggestion: leave the order of calculation as is but remove the MAX_MONEY limit for the balance.
A more accurate solution is to re-develop balance calculation and process both spent and unspent utxos in the same loop providing the order of spending (transaction affinity)