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.

Sign up for GitHub

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

Jump to bottom

block_production.py is flaky #3143

Closed
SkidanovAlex opened this issue Aug 11, 2020 · 0 comments · Fixed by #3173
Closed

block_production.py is flaky #3143

SkidanovAlex opened this issue Aug 11, 2020 · 0 comments · Fixed by #3173
Assignees
@SkidanovAlex
Labels
A-chain Area: Chain, client & related

Comments

@SkidanovAlex
Copy link
Collaborator

Fails with

Traceback (most recent call last):
  File "tests/sanity/block_production.py", line 76, in <module>
    assert min_common() + 2 >= height, heights_report()
AssertionError: None

http://nayduck.eastus.cloudapp.azure.com:3000/#/test/7836
@SkidanovAlex SkidanovAlex added the A-chain Area: Chain, client & related label Aug 11, 2020
@SkidanovAlex SkidanovAlex self-assigned this Aug 11, 2020
@weekly-digest weekly-digest bot mentioned this issue Aug 14, 2020
Closed
SkidanovAlex added a commit that referenced this issue Aug 14, 2020
@SkidanovAlex
fix: Removing flakiness from block_production.py
369f0bf 
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
@SkidanovAlex
fix: Removing flakiness from block_production.py
8001146 
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
@SkidanovAlex
fix: Removing flakiness from block_production.py
6eec2ce 
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
@SkidanovAlex
fix: Removing flakiness from block_production.py
cff89d9 
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 SkidanovAlex mentioned this issue Aug 15, 2020
Merged
SkidanovAlex added a commit that referenced this issue Aug 15, 2020
@SkidanovAlex @bowenwang1996
fix: Removing flakiness from block_production.py (#3173)
48bd846 
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 <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@SkidanovAlex SkidanovAlex

Labels
A-chain Area: Chain, client & related
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

fix: Removing flakiness from block_production.py near/nearcore
1 participant
@SkidanovAlex