Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

getblocks retry 5 times before giving up #117

Closed
wants to merge 1 commit into from
Closed
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
21 changes: 18 additions & 3 deletions src/new_index/fetch.rs
Original file line number Diff line number Diff line change
Expand Up @@ -82,9 +82,24 @@ fn bitcoind_fetcher(
spawn_thread("bitcoind_fetcher", move || {
for entries in new_headers.chunks(100) {
let blockhashes: Vec<BlockHash> = entries.iter().map(|e| *e.hash()).collect();
let blocks = daemon
.getblocks(&blockhashes)
.expect("failed to get blocks from bitcoind");

let mut attempts = 5;
let blocks = loop {
attempts -= 1;

match daemon.getblocks(&blockhashes) {
Ok(blocks) => break blocks,
Err(e) => {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perhaps this should explicitly check for "Block not found on disk" errors and terminate the thread for other unexpected errors?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

On a second thought non recoverable errors will panic anyway after 5 attempts, while recoverable errors will leave a trace in the logs. Are we sure we don't want to retry with any error?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Anyway, I opened #118 which retry only on "Block not found on disk", one or the other is fine for me

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks. I generally prefer to fail fast, if both are fine by you then I would go with #118

(Perhaps also worth mentioning that the daemon already detects connection errors and retries for all RPC commands, so the explicit "Block not found on disk" handling here is done on top of that behavior.)

// There is a small chance the node returns the header but didn't finish to index the block
log::warn!("getblocks failing with: {e:?} trying {attempts} more time")
}
}
if attempts == 0 {
panic!("failed to get blocks from bitcoind")
}
thread::sleep(std::time::Duration::from_secs(1));
};

assert_eq!(blocks.len(), entries.len());
let block_entries: Vec<BlockEntry> = blocks
.into_iter()
Expand Down
Loading