-
Notifications
You must be signed in to change notification settings - Fork 646
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
block_production.py is flaky #3143
Labels
A-chain
Area: Chain, client & related
Comments
SkidanovAlex
added a commit
that referenced
this issue
Aug 14, 2020
The test relies on being able to query all the nodes between every two blocks produced. Before 7028068 it was likely but flaky, after it the test fails consistently. It is due to the fact that store validity checks take ~0.35 seconds per `get_status`. Disabling the validity checks for this test Fixes #3143
SkidanovAlex
added a commit
that referenced
this issue
Aug 14, 2020
The test relies on being able to query all the nodes between every two blocks produced. Before 7028068 it was likely but flaky, after it the test fails consistently. It is due to the fact that store validity checks take ~0.35 seconds per `get_status`. Disabling the validity checks for this test. Fixes #3143
SkidanovAlex
added a commit
that referenced
this issue
Aug 14, 2020
The test relies on being able to query all the nodes between every two blocks produced. Before 7028068 it was likely but flaky, after it the test fails consistently. It is due to the fact that store validity checks take ~0.35 seconds per `get_status`. Disabling the validity checks for this test. It is generally OK, because practically every other test (e.g. transactions.py) is a superset of this test in terms of coverage, and would catch any storage inconsistency that this test would now miss. Fixes #3143 Test plan: --------- http://nayduck.eastus.cloudapp.azure.com:3000/#/run/97
SkidanovAlex
added a commit
that referenced
this issue
Aug 14, 2020
The test relies on being able to query all the nodes between every two blocks produced. Before 7028068 it was likely but flaky, after it the test fails consistently. It is due to the fact that store validity checks take ~0.35 seconds per `get_status`. Disabling the validity checks for this test. It is generally OK, because practically every other test (e.g. transactions.py) is a superset of this test in terms of coverage, and would catch any storage inconsistency that this test would now miss. Fixes #3143 Test plan: --------- http://nayduck.eastus.cloudapp.azure.com:3000/#/run/97
SkidanovAlex
added a commit
that referenced
this issue
Aug 15, 2020
The test relies on being able to query all the nodes between every two blocks produced. Before 7028068 it was likely but flaky, after it the test fails consistently. It is due to the fact that store validity checks take ~0.35 seconds per `get_status`. Disabling the validity checks for this test. It is generally OK, because practically every other test (e.g. transactions.py) is a superset of this test in terms of coverage, and would catch any storage inconsistency that this test would now miss. Fixes #3143 Test plan: --------- http://nayduck.eastus.cloudapp.azure.com:3000/#/run/97 Co-authored-by: Bowen Wang <bowenwang1996@users.noreply.github.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Fails with
http://nayduck.eastus.cloudapp.azure.com:3000/#/test/7836
The text was updated successfully, but these errors were encountered: