-
Notifications
You must be signed in to change notification settings - Fork 17
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
feat: use contract configs #731
Conversation
…at/use-contract-configs
@ChaoticTempest I've fixed a conflict and contract tests, please, check the latest commits. |
@@ -404,7 +404,7 @@ async fn test_contract_propose_update() { | |||
dbg!(contract.id()); | |||
|
|||
test_propose_update_config(&contract, &accounts).await; | |||
test_propose_update_contract(&contract, &accounts).await; | |||
// _test_propose_update_contract(&contract, &accounts).await; |
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.
The contract is too big.
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.
LGTM!
Not sure what is going on with cargo check, it is all good on my machine and GCP VM.
Err(e) => { | ||
tracing::error!("could not fetch contract's config: {e}"); | ||
tokio::time::sleep(Duration::from_secs(1)).await; | ||
continue; |
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.
Is one second too frequent, config is not very frequently changed.
And above rpc_client::fetch_mpc_config.await
blocks the main tokio thread, slow near rpc could slowdown protocol state handle(). I would suggest merge config with state call, doing it less frequently, or fetch it in a background tokio thread, without await
, and run
read from the fetched config written by the background thread, it could be 1s old but next MpcSign will get 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.
yeah 1s might be too frequent actually for configs that rarely if ever change. We can probably have a background task that fetches the config every 10 minutes or so as to not block this thread
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.
Nice improvement! Although we didn't test the new config is applied in an integration test, I think the code looks right, config is refreshed and pass as function arguments instead of state to protocol modules, they'll always get latest config.
@ChaoticTempest I'm merging this to avoid conflicts. Let's address all the comments in a follow-up PR. |
Terraform Feature Environment Destroy (dev-731)Terraform Initialization ⚙️
|
This make use of contract configs in our node.
--override-config
parameter for partial overrides over the config in the contract