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

staking2.py consistently fails #2910

Closed
SkidanovAlex opened this issue Jun 26, 2020 · 0 comments · Fixed by #2913
Closed

staking2.py consistently fails #2910

SkidanovAlex opened this issue Jun 26, 2020 · 0 comments · Fixed by #2913
Assignees
Labels
A-chain Area: Chain, client & related C-bug Category: This is a bug

Comments

@SkidanovAlex
Copy link
Collaborator

staking2.py was failing since around 7283fb2, due to incorrect node configuration. staking_repro* tests were not failing after that commit.
It is fixed in 1eb31

However, shortly before that fix staking_repro* tests started failing, it appears that they started failing after 613953.
After the fix for staking2.py I mentioned above, staking2.py is still consistently failing, but now due to a reason similar to staking_repro* tests.

The tests run short epochs, and in each epoch send "fake" staking txs early in the epoch, and then "real" staking txs late in the epoch (and thus "real" txs overwrite the "fake" txs). Both staking2.py and the staking_repro* tests seem to fail by accepting the "fake" staking tx, which usually happens if the "real" tx is not processed in time.

Given the timing of the failures starting, it is likely that slower get_status results in the delay in txs processing. Potentially disabling validity checks in those tests (if that's possible) or increasing the block timeout can help.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-chain Area: Chain, client & related C-bug Category: This is a bug
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants