-
Notifications
You must be signed in to change notification settings - Fork 2k
Conversation
Added a timeout of 10000 ms to each server test file. This is an attempt to solve the timeout issues that we're experiencing with the Mocha tests. Especially, this is hoping to address the build fails that are caused by such timeouts. Issue is described in meanjs#955
@lirantal That's unfortunate :( The build didn't fail due to test timeouts. It was caused by "network connectivity" though. And chance of re-running the build? |
@mleanos You can close and reopen the PR to force Travis to rerun. |
@mleanos Also, that could indicate that the timeout was due to network connectivity issues and an issue with Travis, not with our code. |
@lirantal @ilanbiala Any thoughts on fast tracking this one? I really think it's gonna help out with all the build fails we're having. |
@mleanos I'm ok, but let's see if we get some better ideas from @bastianwegge or anyone else on how to deal with it. |
BTW looks like other projects are using similar method (namely meanio, and mongoose https://github.com/Automattic/mongoose/search?utf8=%E2%9C%93&q=%22this.timeout%22&type=Code) |
@lirantal Fair enough. And yea, it seems like a straight forward method. Especially, since we can't predict the environmental factors that might contribute to these issues. I'm definitely curious to understand what @bastianwegge had in mind though. |
I investigated into the last failing builds on travis and found out that the Would you point me to any failing build you're according to? Since I can't reproduce it neither on my local jenkins nor on travis. Is this a point where mongoose is sometimes taking longer? |
@bastianwegge We've been having trouble with the Travis CI builds when submitting, or committing to, a PR. More often than not the issue seems that the test is taking longer than 2000ms, as indicated on the Travis logs. There may be other issues that are causing a periodic build fail, but mostly they've been the timeout errors, on any given test. There doesn't seem to be a pattern with which tests fail. |
Ok maybe I'm missing out on something. The idea of "let's raise the timeout" didn't look good to me at first. |
As @lirantal pointed out, it seems that others are using the timeout increase as a method to combat these Travis issues. It's been very frustrating to have the builds fail for no apparent reason, other than a test timeout. So I think this may be a fine solution for now. Perhaps, it's something on Travis' side. |
@bastianwegge the timeouts aren't related to node build, they are happening as part of our tests suite when it runs. Some of them are related to interacting with the server API and others are related to database operations |
@lirantal the timeouts michael is having locally are due to his connection from the local machine to mongolab. He's doing it right testing against a service instead of a local database to avoid issues in that case and he convinced me that it makes sense to set up a higher timeout. We never ran into such issues since our Jenkins has a mongodb locally installed that gets cleared before every run. Do you know what database travis uses? |
@bastianwegge we got those timeouts as well on Travis, and I personally also getting them from time to time with a local mongodb installed here |
@bastianwegge I believe travis is using a local mongo instance inside the container that the tests are ran in. |
Yeah, seems to be just fine if nobody's concerned, I just wanted to jump to make you think about it. Go ahead and merge it, let's see if this breakes down the whole "timout" discussion. Otherwise I'd love to investigate with you into it ! 👍 |
Cool. |
Mocha test timeouts [fixes #955]
Added a timeout of 10000 ms to each server test file. This is an attempt
to solve the timeout issues that we're experiencing with the Mocha
tests. Especially, this is hoping to address the build fails that are
caused by such timeouts.
Issue is described in #955