test(congestion_control) - Implemented nayduck tests for congestion control #11429
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #11429 +/- ##
==========================================
- Coverage 71.36% 71.35% -0.01%
==========================================
Files 784 784
Lines 158134 158137 +3
Branches 158134 158137 +3
==========================================
- Hits 112853 112845 -8
- Misses 40408 40422 +14
+ Partials 4873 4870 -3
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
There was a problem hiding this comment.
Looks good to me, we can always iterate and extend as much as we think we have to.
Also, thinking about this e2e kind of testing, you might be interested in my draft for RPC level rejections (#11419), which would open the door to look for ShardCongested errors in the assertions.
But it's still a draft, mostly just so I had something to point the tooling community to. I think the rough idea should stay the same, unless someone finds an issue with my approach. But I'll need to fix existing congestion tests that don't like that RPCs return an error before it's ready to review and merge.
| gas_used = chunk['header']['gas_used'] | ||
| self.assertGreaterEqual(gas_used, 1000 * TGAS) | ||
|
|
||
| # Check that the congestion info has no buffered receipts and some deleted receipts. |
There was a problem hiding this comment.
probably you meant delayed here?
| # Check that the congestion info has no buffered receipts and some deleted receipts. | |
| # Check that the congestion info has no buffered receipts and some delayed receipts. |
|
|
||
| // Burn the given amount of gas. This is the ultimate overcharging function | ||
| // as it doesn't take almost any resources to execute but burns a lot of | ||
| // gas. | ||
| ##["test_features"] burn_gas<[gas: u64] -> []>, |
Implemented a nayduck test for congestion control. It's more complex than I was hoping for and it still only check a simple scenario all to one, one hop transactions. Still it's a good starting point.