You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently the fixturenet-{plugeth-}eth tests discriminate the result by mean of a check that the chain block height advances over a time interval. The idea being that if the chain isn't working, there either won't be a block height, or it will be stuck at zero (or possibly some other number close to zero).
Problem is that the current code for making this determination is sensitive to timing. It just waits a fixed number of seconds. On a slow test runner this time can be too short. But we don't want the test to take forever to run on a fast machine.
It would be better if the block height check was done in a polling loop -- check for a height, if none found wait a bit then check again. Keep doing that for some fairly long time. Then same thing for checking for the second block height. Using this approach the test would adapt to the speed of the runner and only take a long time on a slow machine, or in the event the test is going to fail (because the block height never advances).
The text was updated successfully, but these errors were encountered:
Currently the fixturenet-{plugeth-}eth tests discriminate the result by mean of a check that the chain block height advances over a time interval. The idea being that if the chain isn't working, there either won't be a block height, or it will be stuck at zero (or possibly some other number close to zero).
Problem is that the current code for making this determination is sensitive to timing. It just waits a fixed number of seconds. On a slow test runner this time can be too short. But we don't want the test to take forever to run on a fast machine.
It would be better if the block height check was done in a polling loop -- check for a height, if none found wait a bit then check again. Keep doing that for some fairly long time. Then same thing for checking for the second block height. Using this approach the test would adapt to the speed of the runner and only take a long time on a slow machine, or in the event the test is going to fail (because the block height never advances).
The text was updated successfully, but these errors were encountered: