-
Notifications
You must be signed in to change notification settings - Fork 256
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
client: Timeout resends during send_and_confirm_in_parallel
#358
Conversation
.collect::<Vec<_>>(); | ||
let num_txs_to_resend = txs_to_resend_over_tpu.len(); | ||
let message = if tokio::time::timeout( | ||
Duration::from_secs(5), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should be BLOCKHASH_REFRESH_RATE
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I thought about it, but worried it would overload the constant to use it in a different setting, since this number was chosen arbitrarily, and not because of BLOCKHASH_REFRESH_RATE
. But if you think it's clearer, I'm happy to change it!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I thought you just overlooked this constant. It looks confusing because it has the same value and because it is unnamed while others are named. So I think there should be comment saying that this constant has been empirically chosen or a different constant
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I added in a comment, let me know how it looks!
Backports to the beta branch are to be avoided unless absolutely necessary for fixing bugs, security issues, and perf regressions. Changes intended for backport should be structured such that a minimum effective diff can be committed separately from any refactoring, plumbing, cleanup, etc that are not strictly necessary to achieve the goal. Any of the latter should go only into master and ride the normal stabilization schedule. Exceptions include CI/metrics changes, CLI improvements and documentation updates on a case by case basis. |
* client: Timeout resends during `send_and_confirm_in_parallel` * Clarify constant (cherry picked from commit 36c66f5)
@@ -326,21 +326,20 @@ async fn confirm_transactions_till_block_height_and_resend_unexpired_transaction | |||
); | |||
} | |||
|
|||
if let Some(progress_bar) = progress_bar { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Doesn't this immediately overwrite the previous progress bar message here:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah true, it's totally unnecessary, I put in #1073 to remove it
…(backport of anza-xyz#358) (anza-xyz#384) client: Timeout resends during `send_and_confirm_in_parallel` (anza-xyz#358) * client: Timeout resends during `send_and_confirm_in_parallel` * Clarify constant (cherry picked from commit 36c66f5) Co-authored-by: Jon C <me@jonc.dev>
Problem
The CLI sometimes gets stuck when deploying programs, as mentioned at #348 (comment)
Summary of Changes
The system for sending and confirming is properly updating the blockhash, and the resending task is checking that, so we're doing all the right things! Most likely, the system is getting stuck during the resend call, so the solution here is to timeout the resend.
I've also reduced the block height refresh time to 5 seconds, because it can be annoying to see nothing changing for a long time. I've also added in logging for the resending, that way it'll look to users that something is actually happening.