-
Notifications
You must be signed in to change notification settings - Fork 11.9k
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
Possible race condition in GovernorPreventLateQuorum
tests
#4049
Comments
Hello @r0qs We also noticed some issues running test since the transition to Note that in the case of the particular test you are pointing, |
Related: #4046 |
Hi @Amxx , thanks for the prompt reply! Right, yeah, to be honest, don't take my words as definitive for the real cause of the problem. I only had a quick look and I don't really know the whole code base, so I'm probably completely wrong in my assumptions. But my guess was due to a stacktrace like this one, which sometimes I got:
So I imagined that it would be a problem on writing/reading the |
Pretty sure it's not a race condition, just flakiness due to how the test chain's timestamps are manipulated in the test suite. |
Fixed by #4046. |
Hi, we recently noticed some random failures in our external tests of the
openzeppelin-contracts
. You can see two sample logs from our CI here:Debugging it locally and isolating one of the failed tests (the first one). The test finishes successfully, so I suspect that there may be some race conditions in the tests.
💻 Environment
Our tests run with a combination of settings of the solidity compiler, but all those pass when running individual openzeppelin tests (i.e. using
it.only
), but some of them randomly fail when running the full openzeppelin test suit.For reference, you can see the full log of that test case (i.e.
Delay is extended to prevent last minute take-over
) that fails when running all tests in the CI but passes if ran alone:📝 Details
I suspect that the bug was introduced by the new test/helpers/time.js added by this PR #3934.
You can see that the
extendedDeadline
was changed here to useclockFromReceipt
: 790cc5b#diff-9b993baaba0944c3ab49a694eb5e65a5b2067339f3b62fbfcfdd0be2aaf859c9L110 for one of the test cases that is failing.It now does:
But before that PR it was:
As
clockFromReceipt
is a global object in whichmode
can be set toblocknumber
ortimestamp
property, and theblocknumber
is a future that returns theblocknumber
, I wonder if it may be the case of a race condition accessingblocknumber
in multiple tests when usingwaitForDeadline
(which in turn callstime.advanceBlockTo
) andclockFromReceipt
.The text was updated successfully, but these errors were encountered: