-
Notifications
You must be signed in to change notification settings - Fork 717
feat(synth-bm): allow multiple account prefixes #12935
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
Conversation
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.
Thanks, overall LGTM, please just store prefixes in a Vec<String>
.
benchmarks/synth-bm/src/account.rs
Outdated
/// - `a_user_<i>.<signer_account_id>,b_user_<i>.<signer_account_id>` | ||
/// if `sub_account_prefixes == Some("a,b")` | ||
#[arg(long, alias = "sub_account_prefix")] | ||
pub sub_account_prefixes: Option<String>, |
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.
Storing prefixes in a Vec<String>
would be more intuitive and requires just some minor tweaks.
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.
Done!
Err(err) => { | ||
let msg = format!("RPC call failed: {}", err); | ||
warn_or_panic(&msg, self.response_check_severity); | ||
} |
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.
Good catch!
cc @Trisfald who is also working on using |
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 but please address comments from others
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #12935 +/- ##
==========================================
+ Coverage 70.35% 70.48% +0.13%
==========================================
Files 854 854
Lines 175420 175591 +171
Branches 175420 175591 +171
==========================================
+ Hits 123412 123766 +354
+ Misses 46881 46681 -200
- Partials 5127 5144 +17
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
During benchmarking I wanted to spawn txs between different shards, and for that it was convenient to use prefixes in the form `2,c,h,m,x`. Would it make sense in general? I retain `sub_account_prefix` as alias. Also I had an issue with RPC node crashing: `[2025-02-13T21:19:04Z WARN near_synth_bm::rpc] RPC call failed: error while sending payload: [error sending request for url (http://34.132.32.11:3030/)]` However, `response_check_severity` states that we can afford such errors, and it makes sense because they are very rare. So I suggest to use `warn_or_panic` for it as well.
During benchmarking I wanted to spawn txs between different shards, and for that it was convenient to use prefixes in the form `2,c,h,m,x`. Would it make sense in general? I retain `sub_account_prefix` as alias. Also I had an issue with RPC node crashing: `[2025-02-13T21:19:04Z WARN near_synth_bm::rpc] RPC call failed: error while sending payload: [error sending request for url (http://34.132.32.11:3030/)]` However, `response_check_severity` states that we can afford such errors, and it makes sense because they are very rare. So I suggest to use `warn_or_panic` for it as well.
During benchmarking I wanted to spawn txs between different shards, and for that it was convenient to use prefixes in the form
2,c,h,m,x
. Would it make sense in general? I retainsub_account_prefix
as alias.Also I had an issue with RPC node crashing:
[2025-02-13T21:19:04Z WARN near_synth_bm::rpc] RPC call failed: error while sending payload: [error sending request for url (http://34.132.32.11:3030/)]
However,
response_check_severity
states that we can afford such errors, and it makes sense because they are very rare. So I suggest to usewarn_or_panic
for it as well.