46dbf027af
The changes are somewhat simple but should solve two issues: - When quickly changing between chains once and a second time back again, batchIds would collide and cause havoc. - If we got an out of range response from a peer, sync would remain in syncing but without advancing Changes: - remove the batch id. Identify each batch (inside a chain) by its starting epoch. Target epochs for downloading and processing now advance by EPOCHS_PER_BATCH - for the same reason, move the "to_be_downloaded_id" to be an epoch - remove a sneaky line that dropped an out of range batch without downloading it - bonus: put the chain_id in the log given to the chain. This is why explicitly logging the chain_id is removed |
||
|---|---|---|
| .. | ||
| beacon_chain | ||
| client | ||
| eth1 | ||
| eth2_libp2p | ||
| genesis | ||
| network | ||
| operation_pool | ||
| rest_api | ||
| src | ||
| store | ||
| tests | ||
| timer | ||
| websocket_server | ||
| Cargo.toml | ||