-
Notifications
You must be signed in to change notification settings - Fork 1.2k
test: set 0.05s delay for wait_until in functional tests #6631
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
base: develop
Are you sure you want to change the base?
Conversation
…waiting votes to be propagated be9cf82 test: fix intermittent failure in feature_governance.py waiting votes to be propagated (Konstantin Akimov) Pull request description: ## Issue being fixed or feature implemented While implementing #6631 found instability in feature_governance.py ## What was done? Governance votes are not delivered instantly between notes. If any vote is delayed a bit the wrong amount of votes will be remembered and test will fail further when comparing its count. ## How Has This Been Tested? Tested locally with changes from #6631 without them - 90+% probability feature_governance.py to fail, with them - no failure happens locally. ## Breaking Changes N/A ## Checklist: - [x] I have performed a self-review of my own code - [ ] I have commented my code, particularly in hard-to-understand areas - [ ] I have added or updated relevant unit/integration/functional/e2e tests - [ ] I have made corresponding changes to the documentation - [x] I have assigned this pull request to a milestone ACKs for top commit: UdjinM6: utACK be9cf82 Tree-SHA512: 113f22314c1a269bfe804e8ad3f1aa02dd31155af08f073345bce52d93d23746cee543814f5b44791698e40eca843a747660fddf2a4eafb235c3b3044fe06ba6
fd6ce4f
to
1017a12
Compare
Quorums are already generated and mined, all calculations are done. Waiting long (0.5seconds) is not necessary Bumping mocktime and generation new blocks no useful anymore
Same delay is used for Bitcoin Core. Though, it can be appliable directly for each usages such as quorum generation or waiting for IS lock. It happends because some functional tests not only waiting during delay, but also does something strange such as bumping mocktime or generating new blocks. Also, some works during quorum generation are assuming to be done while we waiting, but it's not properly validated after delay, just assumed as it is done.
WalkthroughThe changes adjust the polling intervals in wait loops within the test framework and related functional tests. The default sleep interval in the core Note ⚡️ AI Code Reviews for VS Code, Cursor, WindsurfCodeRabbit now has a plugin for VS Code, Cursor and Windsurf. This brings AI code reviews directly in the code editor. Each commit is reviewed immediately, finding bugs before the PR is raised. Seamless context handoff to your AI code agent ensures that you can easily incorporate review feedback. Note ⚡️ Faster reviews with cachingCodeRabbit now supports caching for code and dependencies, helping speed up reviews. This means quicker feedback, reduced wait times, and a smoother review experience overall. Cached data is encrypted and stored securely. This feature will be automatically enabled for all accounts on May 16th. To opt out, configure 📜 Recent review detailsConfiguration used: CodeRabbit UI 📒 Files selected for processing (3)
🔇 Additional comments (6)
✨ Finishing Touches
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
Issue being fixed or feature implemented
Waiting for 0.5s in functional test for every action is a bit excessive, especially for p2p tests that sending messages by localnetwork and waiting at least 0.5 seconds before checking if message is received.
What was done?
Decreasing default delay from 0.5s to 0.05s. It affects mostly p2p tests, but many other tests become faster too.
For quorum formation; for sporks and some other dash specific features bigger delays (0.5s, 1s) are used and they are out of scope of this PR.
How Has This Been Tested?
Speed up on CI for 30% and more.
[develop] linux64-test https://gitlab.com/dashpay/dash/-/jobs/10049432489
ALL | ✓ Passed | 7241 s (accumulated)
Runtime: 1272 s
[PR] linux64-test https://gitlab.com/dashpay/dash/-/jobs/10067158169
ALL | ✓ Passed | 5421 s (accumulated)
Runtime: 938 s
-25%
[develop] linux64-nowallet https://gitlab.com/dashpay/dash/-/jobs/10049432511
ALL | ✓ Passed | 2739 s (accumulated)
Runtime: 488 s
[PR] linux64-nowallet https://gitlab.com/dashpay/dash/-/jobs/10067158174
ALL | ✓ Passed | 1232 s (accumulated)
Runtime: 243 s
-49%
[develop] linux64-tsan https://gitlab.com/dashpay/dash/-/jobs/10049432499
ALL | ✓ Passed | 10399 s (accumulated)
Runtime: 2023 s
[PR] linux64-tsan https://gitlab.com/dashpay/dash/-/jobs/10072993489
ALL | ✓ Passed | 8710 s (accumulated)
Runtime: 1543 s
-25%
[develop] Functional tests on localhost (-O3, debug, no sanitizers, -j20):
ALL | ✓ Passed | 6680 s (accumulated)
Runtime: 372 s
[PR] Functional tests on localhost (-O3, debug, no sanitizers, -j20):
ALL | ✓ Passed | 4609 s (accumulated)
Runtime: 365 s
Benefits of running locally in 20 parallel jobs are very slight. Accumulated time is decreased for 40% as expected, but total time is decreased just for 2%.
It is because the slowest tests requires many quorums to be formed and they are still slow.
Breaking Changes
N/A
Checklist: