Latch is_initial_block_download_finished flag
#1124
Conversation
pavel-kokolemin
requested review from
muursh,
erubboli,
iljakuklic,
TheQuantumPhysicist and
azarovh
as code owners
pavel-kokolemin
force-pushed
the
latch_ibd_flag
branch
from
2c8c3d7
to
7b1af85
Compare
| // TODO: Add a check for importing and reindex. | ||
|
|
||
| // TODO: Add a check for the chain trust. |
There was a problem hiding this comment.
I wonder whether these TODOs are still relevant (and if so, what they actually mean).
There was a problem hiding this comment.
The first one: It's about reindexing. Reindexing is the process of reparsing blocks such that the database can be rebuilt. This is useful in cases of database corruption or when settings like "tx index" are changed. If the reindex process is happening, then it's always true that we're in the "initial block download" state.
The second one: Assuming a monolithic network that we work on during the mainnet, the chain-trust always goes up. Given that, on every release, we can say that a chain-trust below a certain point is always an "initial block download", because we know that the monotonous mainnet must be longer than that point.
Yes, both points are still relevant. But they're more like optimizations than necessities.
| if self.is_fresh_block(&tip_timestamp) { | ||
| self.is_initial_block_download_finished.set(); | ||
| } | ||
|
|
||
| Ok(()) |
There was a problem hiding this comment.
I wonder whether we should write is_initial_block_download_finished to the DB once it becomes true, so that if the node is relaunched, it doesn't get reset to false again.
There was a problem hiding this comment.
It should be reset when the node is shutdown, because the node could be down for a while and hence the "redownload" process should be started again.
There was a problem hiding this comment.
It should be reset when the node is shutdown, because the node could be down for a while and hence the "redownload" process should be started again.
Something similar can happen when the network is down for a while but the node keeps on running. Once we're reconnected, the node has to catch up. How should that be handled? Seems the current PR prevents the node from reverting into the IBD stage in that case but maybe it should be handled somehow too.
There was a problem hiding this comment.
Under normal operation circumstances, the node should never fall back. Besides, the IBD state should be seen as an optimization, more than it being a global state.
pavel-kokolemin
force-pushed
the
latch_ibd_flag
branch
from
7b1af85
to
51853a4
Compare
Remove Result because it can't fail now
pavel-kokolemin
force-pushed
the
latch_ibd_flag
branch
from
51853a4
to
d42ceaa
Compare
No description provided.