Skip to content
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

test: congestion control protocol upgrade #11273

Merged
merged 3 commits into from
May 10, 2024

Conversation

jakmeier
Copy link
Contributor

@jakmeier jakmeier commented May 9, 2024

Add 2 integration tests to check the protocol upgrade works.

The first test is without any traffic at all. This already works.

The second test is with congestion at the time of the upgrade. We haven't handled congestion initialization, yet, therefore the last check is disabled with a TODO comment.

Add 2 integration tests to check the protocol upgrade works.

The first test is without any traffic at all. This already works.

The second test is with congestion at the time of the upgrade.
We haven't handled congestion initialization, yet, therefore
the last check is disabled with a TODO comment.
@jakmeier jakmeier requested a review from wacban May 9, 2024 10:23
@jakmeier jakmeier requested a review from a team as a code owner May 9, 2024 10:23
Copy link

codecov bot commented May 9, 2024

Codecov Report

Attention: Patch coverage is 71.42857% with 2 lines in your changes are missing coverage. Please review.

Project coverage is 70.97%. Comparing base (fefea43) to head (d1221ff).
Report is 7 commits behind head on master.

Files Patch % Lines
core/primitives/src/test_utils.rs 33.33% 1 Missing and 1 partial ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##           master   #11273      +/-   ##
==========================================
- Coverage   70.99%   70.97%   -0.03%     
==========================================
  Files         780      781       +1     
  Lines      154984   155423     +439     
  Branches   154984   155423     +439     
==========================================
+ Hits       110037   110307     +270     
- Misses      40204    40355     +151     
- Partials     4743     4761      +18     
Flag Coverage Δ
backward-compatibility 0.24% <0.00%> (-0.01%) ⬇️
db-migration 0.24% <0.00%> (-0.01%) ⬇️
genesis-check 1.40% <0.00%> (-0.01%) ⬇️
integration-tests 37.10% <71.42%> (-0.05%) ⬇️
linux 69.04% <14.28%> (+0.14%) ⬆️
linux-nightly 70.42% <71.42%> (-0.05%) ⬇️
macos 50.82% <0.00%> (-1.80%) ⬇️
pytests 1.63% <0.00%> (-0.01%) ⬇️
sanity-checks 1.42% <0.00%> (-0.01%) ⬇️
unittests 65.40% <0.00%> (-0.19%) ⬇️
upgradability 0.29% <0.00%> (-0.01%) ⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Copy link
Contributor

@wacban wacban left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, great stuff

Comment on lines 32 to 34
// The immediate protocol upgrade needs to be set for this test to pass in
// the release branch where the protocol upgrade date is set.
std::env::set_var("NEAR_TESTS_IMMEDIATE_PROTOCOL_UPGRADE", "1");
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That is strange, the default should be immediate. This env variable should only be needed on the release branch where the voting date is scheduled in the future. What happens if you remove it? Are you by any chance based on a release branch or do you have the voting date set? You can grep for PROTOCOL_UPGRADE_SCHEDULE to check that.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, no I just copy-pasted this from similar tests. I thought we should set it already to not break things on the release branch later.
I think I can just remove it and CI is still green.

env.upgrade_protocol_to_latest_version();

// check we are in the new version
let block = env.clients[0].chain.get_head_block().unwrap();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

micro nit - Since you read the block here I was expecting that it'll be used for the check in the next line but actually you do that with env. Can you move this line two lines below?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

true, too much frantic moving around of code :)

Comment on lines 141 to 142
let block = env.clients[0].chain.get_head_block().unwrap();
assert!(ProtocolFeature::CongestionControl.enabled(block.header().latest_protocol_version()));
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

funnily enough here you actually use the block :)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh, yeah, good catch. This is actually wrong! We don't care about the latest known protocol version of the block producer, we want to know the epoch protocol version.

signer,
deposit,
// easy way to burn all attached gas
"loop_forever".to_owned(),
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We could use a host function "burn_gas" that would burn gas but not waste the time and CPU to do so ;) Absolutely no need to do it in this PR thought.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah, kind of hurts to let the CPU spin round and round ^^

Good idea to add a host function! Something to maybe discuss with the runtime team how to do it best, adding it to the runtime interface with a NEP and protocol upgrade seems a bit overkill, so maybe it could be a test_features-only thing.

- use epoch protocol version rather than block field for checking that the upgrade worked
- don't set NEAR_TESTS_IMMEDIATE_PROTOCOL_UPGRADE unnecessarily
- typos
@jakmeier jakmeier enabled auto-merge May 9, 2024 17:13
@jakmeier jakmeier added this pull request to the merge queue May 10, 2024
Merged via the queue into near:master with commit ef64846 May 10, 2024
26 of 29 checks passed
@jakmeier jakmeier deleted the congestion-upgrade-integration-test branch May 10, 2024 07:38
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants