-
-
Notifications
You must be signed in to change notification settings - Fork 7.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
e2e test => Jest did not exit one second after the test run has completed. #1538
Comments
Just tested it with the newest version of nest (5.7.0) which also doesn't work. |
We can't help you without at least a small repository which reproduces your issue. |
@kamilmysliwiec i updated the |
confirm that v5.6.2 also got this issue. I have to use |
@kamilmysliwiec did you found something? |
push |
This is not a framework bug - you have an issue in your code. If you remove the redis part, it's going to work correctly which means that some of your async operations (or even connection) haven't fulfilled correctly. Please, use StackOverflow for such questions. |
I already started a stack overflow question. But i got no answer. If you really think that my code is wrong, then tell me please where the wrong code is. |
@danieldaeschle I ran into a similar issue, and determined what my issue was. When using socket.io-client, I establish a connection by calling a .connect(..) method and providing the host and port of where my server is listening on. It turns out, I was accidentally calling io.connect('localhost:3000') in more than one location in my test file. (Once in a beforeEach section, and once within the unit test itself). To clean up my connections, I had to call a .disconnect(true) function. But before this worked for me, I had to catch the duplicate .connect(..) call that I was making, which likely meant there was some unhandled async operation going on that I wasn't cleaning up before jest finished. All in all I'm really glad Jest actually doesn't kill itself when it notices unhandled async ops. @kamilmysliwiec 's advice that your problem isn't a framework bug and that the issue is likely in your code is probably accurate. Go ahead and find out how people close redis connections, then verify you are closing any connections you've opened in the right location (in the end of your unit test, in an afterEach block, or in an afterAll block.), and also verify that you aren't opening the connection more than once accidentally like I was. |
I had the same issue. I was connecting to Pusher with a real key. When switching to a fake key, it solved the problem for me. |
I have this issue and I do think there's something wrong on the framework level, or at least the documentation is unclear. In my case, I try to run a websocket server with the beforeAll(async () => {
const moduleFixture: TestingModule = await Test.createTestingModule({
imports: [AppModule],
}).compile();
app = moduleFixture.createNestApplication();
app.enableCors();
// IF I UNCOMMENT THIS LINE, JEST FINISHES FINE
app.useWebSocketAdapter(new RedisIoAdapter(app));
await app.init();
const address = app
.getHttpServer()
.listen()
.address();
baseAddress = `http://[${address.address}]:${address.port}/editing/story`;
});
afterAll(async () => {
await app.close();
}); RedisIOAdapter is copy-pasted from https://docs.nestjs.com/websockets/adapter. Redis is running happily on the machine. I am 100% sure i'm closing all connections in the test (in |
This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
I'm submitting a...
Current behavior
Run jest with

--runInBand
parameter.Expected behavior
If i run it without this parameter it works like expected.
But on gitlab CI i don't use this parameter and it doesn't work too.
Minimal reproduction of the problem with instructions
nestjs-jest-e2e-test-bug.tar.gz
Install redis server locally and run this commands:
What is the motivation / use case for changing the behavior?
It doesn't work and it should work because this is a nice framework!
Environment
The text was updated successfully, but these errors were encountered: