I am developing a backend service using meanjs.org scaffold. I have written around 1700 tests and they were working fine. But now, tests just started to act weird. Suddenly a lot of tests fails with error:
Error: timeout of 10000ms exceeded. Ensure the done() callback is being called in this test.
Callback done() is being called so this is not the problem. The tests were working all the time but now they don't want to work any more. I tried to drop the mongo database, to stop and start mongod process but nothing works.
Did anyone have the same problem of tests not working from time to time?
I answered a similar post maybe it will be helpfull, as the solution is the same.
mocha timout
The problem is that your connection to mongodb probably exceeds the 2000ms timout from mocha.
Related
We have our selenium server (java) which is opening an electron app to test. During our tests, it seems to just lose the program/process control when we make any non XHR request i.e. any TCP request (via tools like serialport) or if we do a DNS lookup for an app. When the execution of such code happens, things just stop working (the code is async and never comes into the try catch block that is enclosing it) and the test fails.
Has anyone seen this type of issue before?
This is not about pinning down the hang as such, its more about wondering if there is a way to make testcafe decide the test must be a failure after a given period of time.
Our test works fine on local machines, but occasionally when run in CI using a docker image on semaphore one of the selectors causes it to hang. I am fine ivestigating why that is, but it would be good if I could tesll the test to give up after say 5 minutes (it should finish in under 3) and exit gracefully so we can have the stack trace and video - if we have to kill the test run we don;t get either, so we end up having to debug by the logging we emit from the test code.
Currently, this functionality is not implemented in TestCafe. Please track the https://github.com/DevExpress/testcafe/issues/6096 issue to check our progress.
We're facing an issue with handling unexpected behaviours when performing xmlHttpRequests on Android devices using React-Native. We've experienced behaviour where the app becomes unavailable to complete API calls, even though the device is connected to the internet perfectly well (browser can access non-cached sites just fine). The only way to resolve this issue for our users has been to completely restart the app.
To understand the issue and its severity, we wrapped all our API calls to a timer function in production and sent reports to Sentry whenever a request took longer than 30 seconds to finish. Now we've been receiving these kind of reports in the hundreds per day with the duration sometimes being in the hours or even days.
First, instead of using whatwg-fetch, we moved to using axios so that we can manually set the timeout of each request, but this ended up not helping at all.
Second, we dove deeper into understanding how React-Native actually implements timing out XHR requests on Android, and found that it uses OkHttp3 under the hood. OkHttp has a default value for connect, read and write timeouts and react-native allows developers to change the value of connect timeout here. However, OkHttp also has a method for setting a call timeout (everything from connect to reading the response body), but this has a default value of 0 (no timeout) and React-Native doesn't allow users to change that. More on okhttp timeouts here
My question is whether this can be the cause of our worries and whether it should be reported to React-Native as a bug. Lets assume the following case:
app makes an API call to a resource
okhttp is able to connect to the resource within specified timeout limit (default 10s)
okhttp is able to write the request body to the server within timeout limit (10s)
server processes request but for some reason it fails to start sending a response to the client. I guess there could be many reasons for this like server being disconnected, server crashing or server simply losing the connection to the client without the client noticing it. As there is no timeout here, okhttp will happily wait for days on end for the server to start responding to the request.
Am I missing something here or misunderstanding how timeouts work in okhttp? Is there another, perhaps better solution than implementing the ability for developers to set callTimeout on API calls performed on android? And also, isn't it a bit stupid that developers cant set their own write and read timeouts? Cant this lead to unexpected behaviour when you want to send large amounts of data in either direction on a slow connection? 10s is quite long, but perhaps not long enough for all use-cases.
Thanks for your help in advance!
Im randomly getting the error: A MessageReceived handler is blocking the gateway task and when that happens my shard were the error ocurred disconnects without reconnecting.
The problem seems to occur with all the commands. But there is only a small change of it actually occurring. Most of the time the error happens when someone uses the Color = command because that's the most used command.
Im using Discord.net v2.0.0-beta. I switched to the beta because i was having the same issue with 1.0.2
This error occurs when something is running and your bot receives new messages. Your bot wants to process the command, but the previous task is still running so it has to wait for it to finish.
You can fix this by making your bot async. A good introduction to asynchronous programming can be found here.
I'm using the karma-script-launcher to open a virtual machine/browser/url but when the tests are complete I don't know how to close everything.
If I leave the browser open in the virtual machine it eventually stops trying to reconnect - no error message just fails to reconnect. I'm not sure if this is a bug or not. I can't see why you wouldn't want the browser indefinitely trying to reconnect? What ever the reason it leaves me needing to close and re-open the browser each time I run the tests. But if I'm using the script launcher I don't see how this is possible.
Thanks for any help
not quite sure if this covers your answer but I stumbled over your question while looking for a solution to a similar issue, so let me explain - in case someone else encounters this issue.
Was running karma unit tests on codeship ci environment for a nodejs app.
Tests were successful, however the test would keep watching and wouldn't shut down, thus setting the tests to 'passed' - instead it would idle and after a while timeout, setting the tests to 'failed'.
Setting the option singleRun to true within the karma config helped.
Hope this helps anyone who's having the same issue.
Sorry if not topical enough :S