test_loop: add a malicious chunk producer test #12795
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #12795 +/- ##
===========================================
+ Coverage 1.70% 70.44% +68.73%
===========================================
Files 676 854 +178
Lines 121191 174588 +53397
Branches 121191 174588 +53397
===========================================
+ Hits 2065 122986 +120921
+ Misses 119010 46362 -72648
- Partials 116 5240 +5124
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
|
overall looks good to me! |
nagisa
force-pushed
the
add-chunk-producer-test
branch
2 times, most recently
from
72e3a1e to
5fa6826
Compare
|
Alright, I have rebased this. I was meaning to add additional asserts around e.g. heights that all nodes reach, but it seems like that's already done as part of |
nagisa
force-pushed
the
add-chunk-producer-test
branch
from
5fa6826 to
e1948bd
Compare
| let chunk_producer = chunk_producer.clone(); | ||
| let sender = account.clone(); | ||
| let receiver = accounts[0].clone(); | ||
| test_loop.send_adhoc_event(format!("transaction"), move |data| { |
There was a problem hiding this comment.
nit: you don't need format! here
| // For a good measure insert some invalid transactions that may be invalid in other ways than | ||
| // them having been expired. | ||
| let data_clone = node_datas.clone(); | ||
| test_loop.send_adhoc_event(format!("produce chunks without validity checks"), move |_| { |
| let actual = clients.query_balance(account); | ||
| assert_eq!(actual, 1000000 * ONE_NEAR, "no transfers should have happened"); | ||
| } | ||
| test_loop_env.shutdown_and_drain_remaining_events(Duration::seconds(20)); |
There was a problem hiding this comment.
it would be nice to also somehow check that those transactions were actually included in some chunk
There was a problem hiding this comment.
I used prometheus metrics for this.
I went ahead with adding a new metric for the number of transactions that make their way to `fn apply`. That's because the transactions that fail validation don't otherwise end up represended in `TRANSACTION_PROCESSED_TOTAL` anymore.
No description provided.