typeorm health check successful even though connection is broken

[Rainson12]

Is there an existing issue for this?

• I have searched the existing issues

Current behavior

Every now and then our vpn connection from our aws vpc in which the nestjs application is running in breaks. This typically causes the aws ecs container (nestjs application) to restart (due to aws application loadbalancer health check cerification). When the app is back, the healthcheck still often times fails once or twice until finally the vpn connection is back up. However this leads to some strange behaivior. While the healthcheck passes, the database connection in reality doesnt work. So when the first request comes in, we get the following error:

�[31m[Nest] 28 - �[39m08/15/2022, 6:54:03 AM �[31m ERROR�[39m �[38;5;3m[ExceptionsHandler] �[39m�[31mConnection is not established with mysql database�[39m
 TypeORMError: Connection is not established with mysql database
 at /app/node_modules/typeorm/driver/mysql/MysqlDriver.js:710:22

also we get �[31m[Nest] 28 - �[39m08/15/2022, 7:09:41 AM �[31m ERROR�[39m �[38;5;3m[ExceptionsHandler] �[39m�[31mNo metadata for "CaseEntity" was found.�[39m
where as CaseEntity is an entity of our database. The healthcheck controller looks like this:

@ApiTags('Health')
@Controller('health')
export class HealthController {
    constructor(
      private readonly healthCheck: HealthCheckService,
      private readonly typeOrmHealth: TypeOrmHealthIndicator,
    ) {}

    @Get()
    @HealthCheck()
    public async checkHealth(): Promise<HealthCheckResult> {
        return await this.healthCheck.check([async (): Promise<HealthIndicatorResult> => {          
          return await this.typeOrmHealth.pingCheck('db')
        }])
    }
}

Minimum reproduction code

/

Steps to reproduce

we can only reproduce it by using aws vpc and and cut the connection and bring it back during the the launch of the nestjs app. There is no reproduction code, since this is infrastructure related and probably a deeply nested issue with typeorm, nestjs and the mysql driver?

Expected behavior

Either the nestjs application healthcheck should fail or the nestjs application should not boot up.

Package

• I don't know. Or some 3rd-party package
• @nestjs/common
• @nestjs/core
• @nestjs/microservices
• @nestjs/platform-express
• @nestjs/platform-fastify
• @nestjs/platform-socket.io
• @nestjs/platform-ws
• @nestjs/testing
• @nestjs/websockets
• Other (see below)

Other package

@nestjs/terminus

NestJS version

8.1.0

Packages versions

"dependencies": {
    "@nestjs/common": "8.2.5",
    "@nestjs/core": "8.2.5",
    "@nestjs/jwt": "8.0.0",
    "@nestjs/passport": "8.1.0",
    "@nestjs/platform-express": "8.2.5",
    "@nestjs/swagger": "5.1.5",
    "@nestjs/terminus": "8.0.4",
    "@nestjs/typeorm": "8.1.0",
    "class-transformer": "0.4.0",
    "class-validator": "0.12.2",
    "config": "3.3.2",
    "jwt-decode": "3.0.0",
    "lodash": "4.17.20",
    "mysql2": "2.3.3",
    "passport": "0.4.1",
    "passport-jwt": "4.0.0",
    "reflect-metadata": "0.1.13",
    "rimraf": "3.0.2",
    "rxjs": "7.5.2",
    "swagger-ui-express": "4.1.4",
    "typeorm": "0.3.6"
  },
  "devDependencies": {
    "@nestjs/cli": "8.2.0",
    "@nestjs/schematics": "8.0.5",
    "@nestjs/testing": "8.2.5",
    "@types/express": "4.17.3",
    "@types/jest": "27.0.0",
    "@types/jwt-decode": "2.2.1",
    "@types/node": "17.0.9",
    "@types/passport-jwt": "3.0.3",
    "@types/supertest": "2.0.8",
    "@typescript-eslint/eslint-plugin": "3.0.2",
    "@typescript-eslint/parser": "3.0.2",
    "eslint": "7.2.0",
    "eslint-config-prettier": "6.10.0",
    "eslint-plugin-import": "2.24.0",
    "jest": "27.0.0",
    "lodash.clonedeep": "4.5.0",
    "prettier": "1.19.1",
    "supertest": "4.0.2",
    "ts-jest": "27.1.4",
    "ts-loader": "6.2.1",
    "ts-node": "10.7.0",
    "tsconfig-paths": "3.9.0",
    "typescript": "4.5.4"
  }

Node.js version

14.15.4

In which operating systems have you tested?

• macOS
• Windows
• Linux

Other

No response

[kamilmysliwiec]

Please, use our Discord channel (support) for such questions. We are using GitHub to track bugs, feature requests, and potential improvements.