[kamilmysliwiec]

PR Checklist

Please check if your PR fulfills the following requirements:

• The commit message follows our guidelines: https://github.com/nestjs/nest/blob/master/CONTRIBUTING.md
• Tests for the changes have been added (for bug fixes / features)
• Docs have been added / updated (for bug fixes / features)

PR Type

What kind of change does this PR introduce?

• Bugfix
• Feature
• Code style update (formatting, local variables)
• Refactoring (no functional changes, no api changes)
• Build related changes
• CI related changes
• Other... Please describe:

What is the current behavior?

When init() of an application context fails, closing it afterwards tears nothing down. close() rejects with the init error, and no onModuleDestroy, beforeApplicationShutdown or onApplicationShutdown hook runs. Whatever the partial startup acquired stays open: a connection pool a module created before another provider's onModuleInit() threw, timers, sockets. A shutdown signal does the same: it logs the init error as "Error happened during shutdown" and exits with code 1, without running a hook.

const moduleRef = await Test.createTestingModule({ imports: [AppModule] }).compile();

await moduleRef.init().catch(() => {}); // a provider's onModuleInit() throws
await moduleRef.close();
// Rejects with the init error. The database pool is never ended,
// and the test runner hangs on it or leaks it.

The cause is in runShutdownSequence(). Since the change that made a shutdown wait for an initialization in flight, it starts with await this.initializationPromise. After a failed init(), that promise is rejected, so the shutdown rethrows the init error before its first step.

NestApplication doesn't have the problem, because its own init() never sets that promise. So a failed app.init() followed by app.close() already tears down. Standalone application contexts (NestFactory.createApplicationContext()) and TestingModule#init() do have it.

What is the new behavior?

A shutdown still waits for an initialization in flight to settle, but it no longer adopts its failure. The init error has already reached the caller of init(). close() and the signal handlers then run the whole teardown and release what the startup acquired, as they do for HTTP applications. A signal that arrives while an initialization that later fails is still running waits for it, then tears down.

Tests:

• NestApplicationContext:
  • close() after a failed init() runs the destroy and both shutdown hooks;
  • a signal after a failed init() runs the shutdown hooks and re-raises the signal, instead of exiting with 1;
  • a signal during an init() that later fails waits for it to settle, then runs the hooks.
• Integration: a TestingModule whose init() fails calls onApplicationShutdown on close().

Each new test fails without the fix.

Does this PR introduce a breaking change?

• Yes
• No

Other information

close() after a failed init() now resolves if the teardown succeeds, instead of rejecting with the init error again. Code that awaited close() to rethrow the init error would get it from init() already.