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

Beat itest [1/3]: remove the usage of standby nodes #9306

Open
wants to merge 12 commits into
base: yy-waiting-on-merge
Choose a base branch
from

Conversation

yyforyongyu
Copy link
Member

@yyforyongyu yyforyongyu commented Nov 26, 2024

This PR is resulted from fixing the itest failures in blockbeat. Since it's a critical system, we need to make sure the CI is indicative of reporting failures. Check #9260 for the final result.

Improvements

This PR does the following,

  1. All itest flakes are now documented and fixed.
  2. A large decrease in the time taken to run the CI, e.g., for btcd itest, previously it takes 45m and now it takes around 18m.

Changes

  • standby nodes are removed. On one hand, this setup contributes to some of the flakes we've previously seen, e.g., checking num of edges. It creates quite a burden as all the tests are supposed to be independent, and this setup has created unnecessary states that need to be managed. On the other hand, this setup hides bugs, especially when it comes to how the wallet manages UTXOs since it always gives each standby node more than enough UTXOs to use, which is shown in one of the test failures found, in which the ListCoins gives incorrect result and is currently under investigation.

  • tests are shuffled deterministically before running to maximize the tranche scheduler. Out of the 8 tranches in the CI, one of them takes much longer to run due to more blocks mined in this tranche. Since the time it takes to run the test is almost linear to the num of blocks mined, we now shuffle the test cases so it's more likely each tranche mines a similar num of blocks. This setup also gives a faster feedback loop during development, which was why I did it originally. Suppose one change caused 10 tests to fail, with shuffling, we are likely to catch all of them in one CI run, whereas we'd run the CI multiple times previously.

  • most of the table-driven tests are now broken into independent tests, mostly because we want them to be more maintainable, but also contribute to speeding up the CI as the more tests we have, the more likely we get even tranches.

Aside from the above structural changes, all the flakes are now documented, including the ones in windows (windows is less stable, unfortunately). We also assert the shutdown is clean (which contributes to some of the nasty flakes).

Dependent PRs

Issues fixed from this new itest setup, which are dependent PRs,

@yyforyongyu yyforyongyu self-assigned this Nov 26, 2024
Copy link
Contributor

coderabbitai bot commented Nov 26, 2024

Important

Review skipped

Auto reviews are limited to specific labels.

🏷️ Labels to auto review (1)
  • llm-review

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.


Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media?

❤️ Share
🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

  • Review comments: Directly reply to a review comment made by CodeRabbit. Example:
    • I pushed a fix in commit <commit_id>, please review it.
    • Generate unit testing code for this file.
    • Open a follow-up GitHub issue for this discussion.
  • Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
    • @coderabbitai generate unit testing code for this file.
    • @coderabbitai modularize this function.
  • PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
    • @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
    • @coderabbitai read src/utils.ts and generate unit testing code.
    • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
    • @coderabbitai help me debug CodeRabbit configuration file.

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)

  • @coderabbitai pause to pause the reviews on a PR.
  • @coderabbitai resume to resume the paused reviews.
  • @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
  • @coderabbitai full review to do a full review from scratch and review all the files again.
  • @coderabbitai summary to regenerate the summary of the PR.
  • @coderabbitai generate docstrings to generate docstrings for this PR. (Experiment)
  • @coderabbitai resolve resolve all the CodeRabbit review comments.
  • @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
  • @coderabbitai help to get help.

Other keywords and placeholders

  • Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
  • Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
  • Add @coderabbitai anywhere in the PR title to generate the title automatically.

CodeRabbit Configuration File (.coderabbit.yaml)

  • You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
  • Please see the configuration documentation for more information.
  • If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

Documentation and Community

  • Visit our Documentation for detailed information on how to use CodeRabbit.
  • Join our Discord Community to get help, request features, and share feedback.
  • Follow us on X/Twitter for updates and announcements.

@yyforyongyu yyforyongyu added this to the v0.19.0 milestone Nov 26, 2024
Copy link

Pull reviewers stats

Stats of the last 30 days for lnd:

User Total reviews Time to review Total comments
guggero
🥇
29
▀▀▀▀
13h 1m
31
▀▀
yyforyongyu
🥈
11
1d 1h 32m
28
▀▀
ellemouton
🥉
11
16h 30m
21
ziggie1984
8
12h 47m
9
Roasbeef
7
4d 13h 56m
▀▀
47
▀▀▀
ProofOfKeags
3
5d 4h 23m
▀▀
10
Abdulkbk
3
13h 37m
2
ViktorTigerstrom
2
2d 14h 26m
5
alexbosworth
1
4d 11h 58m
▀▀
1
bhandras
1
12h
0
bitromortac
1
16h 16m
0

@yyforyongyu yyforyongyu added itests Issues related to integration tests. flake fix size/kilo medium, proper context needed, less than 1000 lines no-changelog no-itest labels Nov 26, 2024
Copy link
Collaborator

@guggero guggero left a comment

Choose a reason for hiding this comment

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

Very nice! I like the idea of shuffling the tests. And lots of other goodies in this PR as well.
The PR body mentions splitting the sub tests into standalone tests to speed up. I assume that's been moved to a different part of the saga?

Looks like one of the tests fails everywhere but not sure if it's related to this PR or fixed in a later one. So non-blocking since this is being merged into a side branch.

    --- FAIL: TestLightningNetworkDaemon/tranche02/53-of-192/bitcoind/open_channel_reorg_test (38.98s)
        harness_node.go:403: Starting node (name=Alice) with PID=5580
        harness_node.go:403: Starting node (name=Bob) with PID=5600
        miner.go:631: 
            	Error Trace:	/home/runner/work/lnd/lnd/lntest/miner/miner.go:631
            	            				/home/runner/work/lnd/lnd/itest/lnd_open_channel_test.go:70
            	            				/home/runner/work/lnd/lnd/lntest/harness.go:297
            	            				/home/runner/work/lnd/lnd/itest/lnd_test.go:130
            	Error:      	Received unexpected error:
            	            	expected new miner(555) to be 5 blocks ahead of original miner(551)
            	Test:       	TestLightningNetworkDaemon/tranche02/53-of-192/bitcoind/open_channel_reorg_test
            	Messages:   	failed to assert block height delta

itest/lnd_test.go Show resolved Hide resolved
itest/lnd_test.go Show resolved Hide resolved
This commit adds a new flag to shuffle all the test cases before running
them so tests which require lots of blocks to be mined are less likely
to be run in the same tranch.

The other benefit is this approach provides a more efficient way to
figure which tests are broken since all the differnet backends are
running different tranches in their builds, we can identify more failed
tests in one push.
To make sure each run is shuffled, we use the action ID as the seed.
Prepares the upcoming refactor. We now never call `ht.Alice` directly,
instead, we always init `alice := ht.Alice` so it's easier to see how
they are removed in a following commit.
This commit removes the usage of the standby nodes and uses
`CreateSimpleNetwork` when applicable. Also introduces a helper method
`NewNodeWithCoins` to quickly start a node with funds.
This commit removes the standby nodes Alice and Bob.
Since we don't have standby nodes anymore, we don't need to close the
channels when the test finishes. Previously we would do so to make sure
the standby nodes have a clean state for the next test case, which is no
longer relevant.
Soemtimes the node may be hanging for a while without being noticed,
causing failures in its following tests, thus making the debugging
extrememly difficult. We now assert the node has been shut down from the
logs to assert the shutdown process behaves as expected.
This commit fixes a misuse of `ht.Subtest`, where the nodes should
always be created inside the subtest.
This bug was hidden because we used standby nodes before, which always
have more-than-necessary wallet utxos.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
flake fix itests Issues related to integration tests. no-changelog no-itest size/kilo medium, proper context needed, less than 1000 lines
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants