# Travis job fails tests randomly and terminates builds abruptly
**URL:** https://travis-ci.community/t/travis-job-fails-tests-randomly-and-terminates-builds-abruptly/5610
**Category:** Scala
**Created:** [October 22, 2019, 5:18am UTC](https://travis-ci.community/t/travis-job-fails-tests-randomly-and-terminates-builds-abruptly/5610 "2019-10-22T05:18:36Z")
**Posts on this page:** 6
**Page:** 1
### Author:  [@rhande-mdsol](https://travis-ci.community/u/rhande-mdsol)
#### Post date: [October 22, 2019, 5:18am UTC](https://travis-ci.community/t/travis-job-fails-tests-randomly-and-terminates-builds-abruptly/5610/1 "2019-10-22T05:18:36Z")
I have a travis stage which executes a command. This stage runs integration tests which are written using scala test and wiremock.
```auto
script:
- sbt doSomething
```
Assume that `doSomething` runs my integration tests. When this runs on travis, my tests fail randomly. Sometimes fail with 598 network timeout, sometimes 404 or 500. It is highly irregular. Sometimes build stops and shows a message
`No output has been received in the last 10m0s, this potentially indicates a stalled build or something wrong with the build itself. Check the details on how to adjust your build configuration on: https://docs.travis-ci.com/user/common-build-problems/#build-times-out-because-no-output-was-received`
Is there a way to set this timeout to larger value for an sbt project ?
but when I start the same stage in `Debug Mode` and debug that build in `ssh` it opens a path in my mac’s terminal. Then if I run `sbt doSomething` I don’t see any failures, with all tests passing no matter how many times I run the same command.
Ideally both are doing same operations. Why is that it is irregular on travis and why it always passes in quiet mode ? Is that a problem with travis CI ? Is there a way to sort it out ?
---
### Author:  [@native-api](https://travis-ci.community/u/native-api)
#### Post date: [October 22, 2019, 7:14am UTC](https://travis-ci.community/t/travis-job-fails-tests-randomly-and-terminates-builds-abruptly/5610/2 "2019-10-22T07:14:17Z")
Without a link to a build and an [MCVE](https://stackoverflow.com/help/minimal-reproducible-example) of what you are doing locally, I can’t say anything specific.
Most probably, a Travis builder is much less powerful than your local machine which breaks assumptions that your code implicitly makes – things take longer than you expect and/or execute in a different order.
---
### Author:  [@rhande-mdsol](https://travis-ci.community/u/rhande-mdsol)
#### Post date: [October 22, 2019, 8:37am UTC](https://travis-ci.community/t/travis-job-fails-tests-randomly-and-terminates-builds-abruptly/5610/3 "2019-10-22T08:37:52Z")
but is it not that debug mode of travis with `ssh` not same as running on travis directly ?
---
### Author:  [@native-api](https://travis-ci.community/u/native-api)
#### Post date: [October 22, 2019, 8:26pm UTC](https://travis-ci.community/t/travis-job-fails-tests-randomly-and-terminates-builds-abruptly/5610/4 "2019-10-22T20:26:55Z")
Oh, by “opens a path in my mac’s terminal” you meant you are getting an SSH session to Travis machine. I thought that meant that you were running things locally.
It’s the same VM but not _quite_ the same workload: there isn’t logging, the stock build logic doesn’t run and standard stream writes would wait on SSH’s socket if their buffer fills (If there are any other subtle changes like priority boosting to give you a reasonable interactive response time, that’s something only @BanzaiMan or @dominic can answer).
My practice also shows that [there can be significant performance fluctuations from job to job](https://travis-ci.org/skvark/opencv-python/builds/583741987) – presumably from differing loads on VM hosts.
So your best option here IMO is to [make your code give you more information on what is happening](https://stackoverflow.com/questions/47008036/recursionerror-that-happens-only-without-a-debugger/47008130#47008130) so that you have an idea where it’s stuttering if an error occurs. And also sanity-check your test logic for any obvious race conditions (like making sure a server is actually up and running when you are trying to use it).
---
### Author:  [@rhande-mdsol](https://travis-ci.community/u/rhande-mdsol)
#### Post date: [October 24, 2019, 9:43am UTC](https://travis-ci.community/t/travis-job-fails-tests-randomly-and-terminates-builds-abruptly/5610/5 "2019-10-24T09:43:32Z")
Is there way that we can make the actual job analogous to the debug mode ? Something like a lighter version ??
---
### Author:  [@native-api](https://travis-ci.community/u/native-api)
#### Post date: [October 26, 2019, 4:42am UTC](https://travis-ci.community/t/travis-job-fails-tests-randomly-and-terminates-builds-abruptly/5610/6 "2019-10-26T04:42:17Z")
I cannot answer that, only someone from the staff can.
For me, this is a clear case of a [Heisenbug](https://en.wikipedia.org/wiki/Heisenbug) – and as such, you have to run exactly the load that exposes it and examine the program’s state if and when it happens. Altering the environment in any way is not a guarantee that it will go away (because you don’t know what exact combination of circumstances causes the bug). E.g. you could have just happened to get a fast VM for your debug session.