Intermittent issue with Travis build

[alansouzati]

Sometimes my Travis build is failing with the following log:

  ● Test suite failed to run
    ProcessTerminatedError: cancel after 2 retries!

      at Farm.<anonymous> (node_modules/worker-farm/lib/farm.js:81:25)
      at Array.forEach (native)
      at Farm.<anonymous> (node_modules/worker-farm/lib/farm.js:75:36)
      at tryOnTimeout (timers.js:224:11)
      at Timer.listOnTimeout (timers.js:198:5)

Do you want to request a feature or report a bug?

report a bug

What is the current behavior?

https://travis-ci.org/grommet/grommet/builds/161188855#L579

[cpojer]

Can you try to use -i on travis which will run all the tests in one thread instead? I'm thinking this might be a resource problem, like one or many tests are leaking memory or something similar.

[alansouzati]

Thanks for the follow up. I will try this option. One question: if this is a memory leak in my code, should I be able to reproduce it locally? I tried running tests 20x in a roll with multiple threads and I could not reproduce the issue. Also, I haven't heard back from any of our community members regarding this intermittent issue in their locals.

Could this be related to timeout or something? One noticeable difference between my local and Travis is how long a test takes to run in the CI. I'm wondering if this could be related to this issue.

[cpojer]

Travis in general doesn't have a lot of resources so you might not be able to notice this because your CPU and memory is much better than what a travis vm gives you.

[cpojer]

I'm gonna close because there is probably nothing actionable for us and -i has worked in the past. If it turns out to be an issue in Jest and you have a repro, we are happy to help you fix it.

[aaronabramov]

@alansouzati that happened to me a few times and using -i helped.
the reason this was happening was conflicting subprocesses that i spawned from my jest tests. after switching to -i there was only 1 subprocess running at a time and it fixed the issue. It was not reproducible locally as well

[alansouzati]

Thanks for the follow up guys

Sent from my iPhone

On Sep 21, 2016, at 2:25 PM, Dmitrii Abramov notifications@github.com wrote:

@alansouzati that happened to me a few times and using -i helped.
the reason this was happening was conflicting subprocesses that i spawned from my jest tests. after switching to -i there was only 1 subprocess running at a time and it fixed the issue. It was not reproducible locally as well

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

[terkelg]

Thanks @DmitriiAbramov and @cpojer. My travis-build went from being terminated after 16 min to only 1 min 27 sec after adding -i:

script:
  - npm test -- -i

[cpojer]

It really depends on what you are doing in your tests and how you are utilizing your resources. If you spawn a lot of child processes in your tests, running Jest with many processes itself might stall the CPU. In this case, -i can improve performance. Also consider things like -w 2 which will set the number of workers to 2 – you can try half the available ones on your system and see if that improves things, for example.

[davidtheclark]

I've run into this problem in our attempt to migrate stylelint to Jest. I don't understand how it is not an issue that Jest itself needs to address. As an aspiring Jest user, here's what I'm seeing:

• The default Jest settings don't reliably work in CI builds, making CI that uses Jest unreliable — which is a significant problem.
• The only documentation suggesting you should be using -i on CI is buried in a closed issue.
• Even when I do use -i, I'm running into memory allocation failures on Travis that prevent the tests from working as they do locally.

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.
Please note this issue tracker is not a help forum. We recommend using StackOverflow or our discord channel for questions.