OpenZeppelin Test Environment: Timeout exceeding 2000ms

Hi @Jshanks21

Sorry you had this issue.
Are you able to share your test and contract so that I can try to reproduce?

2 Likes

No worries @abcoathup. Sorry for not responding sooner. I just pushed my changes to GitHub. This link should take you directly to the test file. I left a comment next to the line canceling out the error. It’s on line 19. You’ll want to comment this out or remove it to reproduce the error.

Thanks for taking a look!

2 Likes

Hi @Jshanks21,

I wasn’t able to reproduce on my system:
node v10.19.0
npm 6.14.1
operating system: WSL on Windows 10

Would you mind sharing what your configuration is?

I have line 19 commented

	//this.timeout(0); // Prevents 2000ms timeout error

I am not reproducing the error:

$ npm run test

> crowdsale@1.0.0 test /c/Users/andre/Documents/projects/forum/crowdsale
> npx mocha --exit --recursive test



  MyCrowdsale
    crowdsale
      ✓ tracks the token name (54ms)
      ✓ tracks the rate
      ✓ tracks the wallet
      ✓ tracks the token
    minted crowdsale
      ✓ mints tokens after purchase (155ms)
    accepting payments
      ✓ accept payments (199ms)


  6 passing (3s)
2 Likes

No problem @abcoathup:

node v10.16.3
npm 6.13.1
operating system: Windows 10

Commenting line 19

timeout error enabled

Here’s the error I get:

But it passes when I stop commenting line 19:

1 Like

Hi @Jshanks21,

The default timeout in mocha is 2000ms.

The first run of beforeEach I get a duration (ms) ~1200
The beforeEach is deploying a token and a smart contract so takes a little bit of time.

I reproduced by adding a sleep await new Promise(r => setTimeout(r, 2000));

As you have done, you can disable timeouts using this.timeout(0) or you could increase the timeout.
https://mochajs.org/#suite-level


As an aside, I use Windows Subsystem for Linux, and I would recommend using WSL (I haven’t tried WSL2 yet). So much of the ecosystem is unix based, so I run into far fewer issues using WSL.

3 Likes

Thank you @abcoathup! I assumed it had something to do with my tests exceeding the built-in time limit. I also just assumed it was because my computer is too slow :sweat_smile:.

I was actually just reading about a different issue in this thread where you recommended WSL too. I’ll definitely check it out.

I wanted to contribute to the OpenZeppelin repo, so I was going through some of the name changes and cleanup issues in the upcoming release. But I encountered the “file import callback not supported” when trying to compile in order to run tests. Would using WSL be the best solution for this?

1 Like

Hi @Jshanks21,

Great to hear that you want to contribute to OpenZeppelin Contracts. I would encourage using WSL (I am yet to try WSL2), as you face far fewer issues. The Microsoft documentation recommends using Windows Subsystem for Linux (for production): https://docs.microsoft.com/en-us/windows/nodejs/setup-on-windows#use-windows-subsystem-for-linux-for-production.

1 Like

Good to know. I’ll go through that and see if it helps with the issue. Seems like a good idea aside from the immediate issue I’m encountering though.

1 Like

Let me know how you get on. You could always write up the process to get a Windows development environment setup :smile:

1 Like

I should be able to do that. I’ll definitely be adding it to my My Coding Journey when I do it anyway. I’ll just try to be more conscious of tracking each step.

1 Like

Hi @Jshanks21, I have a small follow up question to help us understand the underlying issue better. Was the timeout happening consistently or only sometimes?

1 Like

Hi @frangio, the timeout was consistent. Anytime I ran the tests without this.timeout(0); at the beginning of the tests, I received the error message above.

I appreciate any additional feedback on this.

P.S. I have not tried using WSL yet to see if it fixes the issue. Plan to try it within the next couple days.

2 Likes

The first run of beforeEach I got a duration (ms) ~1200 so on a different setup (e.g. native Windows) I could see this being over the default timeout of 2000ms.

That’s interesting. Do you know which statements took longer? I tried to run this on my own computer but for some reason it doesn’t work.

1 Like

@frangio
The first run in the beforeEach of the test deploying the token takes the longest:

// MyCrowdsale.test.js

...

	beforeEach(async function () {
		// Token config
		this.name = "OZToken";
		this.symbol = "OZT";
		this.decimals = 18;

		start = Date.now();

		// Deploy Token
		this.token = await OZToken.new(
			this.name,
			this.symbol,
			this.decimals
		);

		end = Date.now();


...

Test run

$ npm test

> crowdsale@1.0.0 test /c/Users/andre/Documents/projects/forum/crowdsale
> npx mocha --exit --recursive test



  MyCrowdsale
    crowdsale
Deploy token: 1043ms
Deploy crowdsale: 90ms
Add minter: 77ms
      ✓ tracks the token name (55ms)
Deploy token: 141ms
Deploy crowdsale: 88ms
Add minter: 57ms
      ✓ tracks the rate
Deploy token: 116ms
Deploy crowdsale: 76ms
Add minter: 56ms
      ✓ tracks the wallet
Deploy token: 111ms
Deploy crowdsale: 78ms
Add minter: 55ms
      ✓ tracks the token
    minted crowdsale
Deploy token: 114ms
Deploy crowdsale: 80ms
Add minter: 58ms
      ✓ mints tokens after purchase (208ms)
    accepting payments
Deploy token: 109ms
Deploy crowdsale: 76ms
Add minter: 58ms
      ✓ accept payments (230ms)


  6 passing (3s)
1 Like

Oh thank you this is super interesting. The delay is then caused by the startup time of the ganache node that Test Environment spins up.

2 Likes