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

retry mechanism addition to download bitcoind tarball #1393

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

GitGab19
Copy link
Collaborator

Close #1392

Copy link

codecov bot commented Jan 24, 2025

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 19.08%. Comparing base (55fba7c) to head (f01545c).
Report is 1 commits behind head on main.

Additional details and impacted files
@@           Coverage Diff           @@
##             main    #1393   +/-   ##
=======================================
  Coverage   19.08%   19.08%           
=======================================
  Files         166      166           
  Lines       11066    11066           
=======================================
  Hits         2112     2112           
  Misses       8954     8954           
Flag Coverage Δ
binary_codec_sv2-coverage 0.00% <ø> (ø)
binary_serde_sv2-coverage 3.55% <ø> (ø)
binary_sv2-coverage 5.34% <ø> (ø)
bip32_derivation-coverage 0.00% <ø> (ø)
buffer_sv2-coverage 25.02% <ø> (ø)
codec_sv2-coverage 0.01% <ø> (ø)
common_messages_sv2-coverage 0.13% <ø> (ø)
const_sv2-coverage 0.00% <ø> (ø)
error_handling-coverage 0.00% <ø> (ø)
framing_sv2-coverage 0.28% <ø> (ø)
jd_client-coverage 0.00% <ø> (ø)
jd_server-coverage 7.79% <ø> (ø)
job_declaration_sv2-coverage 0.00% <ø> (ø)
key-utils-coverage 2.39% <ø> (ø)
mining-coverage 2.44% <ø> (ø)
mining_device-coverage 0.00% <ø> (ø)
mining_proxy_sv2-coverage 0.70% <ø> (ø)
noise_sv2-coverage 4.44% <ø> (ø)
pool_sv2-coverage 2.04% <ø> (ø)
protocols 24.57% <ø> (ø)
roles 6.54% <ø> (ø)
roles_logic_sv2-coverage 7.93% <ø> (ø)
sv2_ffi-coverage 0.00% <ø> (ø)
template_distribution_sv2-coverage 0.00% <ø> (ø)
translator_sv2-coverage 9.60% <ø> (ø)
utils 25.13% <ø> (ø)
v1-coverage 2.41% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@GitGab19 GitGab19 force-pushed the add-retry-in-tp-tarball-download branch from 9ec4466 to 979b1d5 Compare January 24, 2025 12:07
@plebhash
Copy link
Collaborator

overall the PR looks good, but the commit title seems a bit confusing... was that intentional?

@jbesraa
Copy link
Contributor

jbesraa commented Jan 24, 2025

Why do we need to specify retries? I think a better approach would be to add a timeout, by default, to the function

@GitGab19 GitGab19 force-pushed the add-retry-in-tp-tarball-download branch from 979b1d5 to 8a60aad Compare January 24, 2025 16:56
@GitGab19
Copy link
Collaborator Author

Why do we need to specify retries? I think a better approach would be to add a timeout, by default, to the function

I did it because I thought that maybe it could be useful for some other future uses. Better than having a default value..

@GitGab19 GitGab19 force-pushed the add-retry-in-tp-tarball-download branch from 8a60aad to f01545c Compare January 24, 2025 16:57
@jbesraa
Copy link
Contributor

jbesraa commented Jan 24, 2025

Why do we need to specify retries? I think a better approach would be to add a timeout, by default, to the function

I did it because I thought that maybe it could be useful for some other future uses. Better than having a default value..

If 503 error code is received then the server is probably overloaded. So if we are doing 10 retries in 3 seconds for example, it is not really helpful, but if we say this function run for 30 seconds and make a request every 3 seconds, it is a big enough time-frame to wait for the server to come up but in the same time not overload it with requests.

@GitGab19
Copy link
Collaborator Author

I agree with you, but there's an incremental delay in this PR to manage that.

It works in this way:

  • 1st attempt --> tries without delay
  • 2nd attempt --> tries after 2^1 seconds
  • 3rd attempt --> tries after 2^2 seconds
    ...

Copy link
Contributor

@Shourya742 Shourya742 left a comment

Choose a reason for hiding this comment

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

ACK with minor nits.

"URL {} didn't return 200",
download_url
fn download_bitcoind_tarball(download_url: &str, retries: usize) -> Vec<u8> {
for attempt in 0..retries {
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
for attempt in 0..retries {
for attempt in 1..=retries {

}
}

if attempt < retries - 1 {
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
if attempt < retries - 1 {
if attempt < retries {

If above suggestion is accepted.

}

if attempt < retries - 1 {
let delay = 2u64.pow(attempt as u32);
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
let delay = 2u64.pow(attempt as u32);
let delay = 1u64 << (attempt - 1);

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Undeterministic TP download in integration tests execution
4 participants