Sync reorg up to history size #3874
Conversation
arkpar
commented
Dec 16, 2016
•
arkpar
commented
- Fixed an issue with sync not being able to recover from a long fork.
- Fixed another issue with peer difficulty not being tracked properly.
- Set default history size back to 1200.
arkpar
added
A3-inprogress ⏳
| @@ -1309,6 +1311,7 @@ impl BlockChainClient for Client { | |||
| PruningInfo { | |||
| earliest_chain: self.chain.read().first_block_number().unwrap_or(1), | |||
| earliest_state: self.state_db.lock().journal_db().earliest_era().unwrap_or(0), | |||
| history_size: Some(self.history), | |||
There was a problem hiding this comment.
should be state_history_size
|
Changes Unknown when pulling 1302b39 on sync-search into ** on master**. |
arkpar
added
A0-pleasereview 🤓
arkpar
added
A3-inprogress ⏳
arkpar
added
A0-pleasereview 🤓
|
Changes Unknown when pulling 69eac0a on sync-search into ** on master**. |
| @@ -1245,7 +1245,9 @@ impl BlockChainClient for Client { | |||
| } | |||
|
|
|||
| fn chain_info(&self) -> BlockChainInfo { | |||
| self.chain.read().chain_info() | |||
| let mut chain_info = self.chain.read().chain_info(); | |||
| chain_info.pending_total_difficulty = chain_info.total_difficulty + self.block_queue.total_difficulty(); | |||
There was a problem hiding this comment.
can't we often have multiple competing blocks from different forks in the queue? (i.e. this value will often be higher than the actual total difficulty of the best queued block)
There was a problem hiding this comment.
This is used to make a decision whether to try and sync to a peer for a full sync. When the queue is full we don't care much if this is precise. When it is empty or nearly empty and we are far behind we don't care either. For the up-to date sync to unknown hashes this is not used because there's no way to get other peer's total difficulty. We treat it as unknown and try and download these new blocks anyway.
rphmeier
added
A8-looksgood 🦄
