[Bug]: Test suite failed to run, thrown: undefined

Version

27.4.7

Steps to reproduce

Unfortunately for the moment I am not sure how it could be reproducible, the issue does not point to anything in my application. Please understand the situation, I am aware that jest-circus was added recently and it might contain bugs.

Edit: Just discovered a way to stop this issue from happening: I had to add this to each test:

describe('FooController', () => {

  let app: NestFastifyApplication;

  beforeAll(async () => {
    app = await initiateApplication();
  });

  afterAll(async () => {
    await new Promise(resolve => setTimeout(resolve, 1000)); // <--- Required to stop the crash
    await app.close();
  });

});

Feels like app.close(); is happening too early and the application is crashing.

(Please click on the images to open)

Expected behavior

All suite tests are passing, but unfortunately due to the undefined error at jest-circus/build/utils.js:566:18 the test is not passing. It’s returning "numRuntimeErrorTestSuites":3 on the Jest’s json report.

Actual behavior

Random instances of this error:

● Test suite failed to run

    thrown: undefined

      at _getError (../node_modules/jest-circus/build/utils.js:566:18)
          at Array.map (<anonymous>)
          at runMicrotasks (<anonymous>)

  ● Test suite failed to run

    thrown: undefined

      at _getError (../node_modules/jest-circus/build/utils.js:566:18)
          at Array.map (<anonymous>)
          at runMicrotasks (<anonymous>)

Additional context

The application uses bull and redis, might have influence? What I could do to better debug this error? I tried to debug but I could not find any essential information pointing to my tests.

Environment

System:
    OS: macOS 12.1
    CPU: (10) x64 Apple M1 Pro
  Binaries:
    Node: 14.18.3 - /usr/local/bin/node
    Yarn: 1.22.17 - /usr/local/bin/yarn
    npm: 6.14.15 - /usr/local/bin/npm
  npmPackages:
    jest: ^27.4.7 => 27.4.7

[julioolvr]

@F3n67u here’s the most minimal example I could come up with https://github.com/julioolvr/jest-nest-issue. Not 100% sure it’s the exact same issue, but it triggers both a thrown: undefined (when Redis is not running) and leaks handles (when Redis is running, although that’s probably https://github.com/nestjs/bull/issues/665).

[julioolvr]

@l-jesse that advise was gold. After some debugging I was able to figure out what’s going on (at least partially). In our case (and I’m assuming also OPs) we have this Nest application with Bull for managing background tasks (which in turn connects to Redis) and multiple e2e specs. One of our spec was failing - the smallest (and fastest) one. After looking into the exception as suggested by @l-jesse, I found it was trying to disconnect from Redis before the connection was established. That is probably why adding a timeout as mentioned by OP fixed it. It also explains why our second e2e spec (longer and slower) would work - it had time to establish the connection properly.

Our solution was to handle creation and teardown of connection ourselves, and waiting for ready. We set up Bull like this:

BullModule.forRootAsync({
  imports: [QueueModule],
  useFactory: (queueClientFactory: QueueClientFactory) => ({
    createClient: (_type, options) => queueClientFactory.build(options),
  }),
  inject: [QueueClientFactory],
}),

Where QueueModule is a small module that exports QueueClientFactory:

import { Module } from '@nestjs/common';
import { QueueClientFactory } from './queue-client-factory.provider';

@Module({
  providers: [QueueClientFactory],
  exports: [QueueClientFactory],
})
export class QueueModule {}

The important part is QueueClientFactory, that creates clients and returns them, but keeps a reference to them to close them all during application shutdown. It waits until they’re ready before doing that:

@Injectable()
export class QueueClientFactory implements OnApplicationShutdown {
  clients: IORedis.Redis[];

  constructor(private configService: ConfigService<ConfigProperties>) {
    this.clients = [];
  }

  build(options: IORedis.RedisOptions | undefined): IORedis.Redis {
    const client = new IORedis(
      this.configService.get('QUEUE_PORT'),
      this.configService.get('QUEUE_HOST'),
      { ...options },
    );

    this.clients.push(client);

    return client;
  }

  async onApplicationShutdown() {
    await Promise.all(
      this.clients
        .filter((client) => client.status === 'connecting')
        .map((client) => {
          return new Promise((resolve) => {
            client.on('ready', resolve);
          });
        }),
    );

    await Promise.all(
      this.clients
        .filter((client) => client.status !== 'end')
        .map((client) => client.quit()),
    );
  }
}

Important note: Even after these changes I still have to add --forceExit to Jest. By adding detectOpenHandles and using leaked-handles I found that a few handles were still open, but couldn’t tell exactly what. It might be unrelated to this issue. At the very least tests pass.

As for why Jest is not more explicit about the error… I don’t know. I was able to find the throw that is passed an undefined but didn’t really spend much time trying to find where does the original error get lost.