Looks like TypeORM error message are suppressed.

[basvdijk]

I'm submitting a...

[ ] Regression 
[ ] Bug report
[ ] Feature request
[x] Documentation issue or request
[ ] Support request => Please do not submit support request here, instead post your question on Stack Overflow.

Current behavior

When connecting to the MSql database I get: "Unable to connect to the database. Retrying (1)"

It turned out this was caused by an entity having @Column('description') which is not allowed and should have beeld @Column() took hours to figure this out since it looks like there is something wrong with the credentials.

Expected behavior

A more verbose way of error e.g. Unable to connect: host unreachable, or password incorrect etc.
Also an option to show the credentials used would be very nice to debug connection issues. Currently I have no clue if the correct credentials are taken from my .env file.

The problem occurred as well when using Entities generated with https://github.com/Kononnable/typeorm-model-generator Apparently there is something wrong with an Entity but the console keeps telling me "Unable to connect to the database. Retrying (1)" instead of giving where something is wrong.

Minimal reproduction of the problem with instructions

Create a DB connection with wrong credentials

What is the motivation / use case for changing the behavior?

Better debugging on connection errors.

Environment

Nest version: 5.0.0

For Tooling issues:
- Node version: 9.9.0
- Platform:  Mac

Others:

[basvdijk]

I've been digging a bit more and figured out the following:

When using TypeORM outside NestJS everything is fine, I see the errors in the terminal and can easily fix them. However when using TypeORM inside NestJS it looks like all messages of TypeORM are suppressed and only "Unable to connect to the database. Retrying (1)" shows up.

[basvdijk]

As an addition, for me as a developer it turned out missing this error info is sort of a deal-breaker for NestJS. When developing I saw [TypeOrmModule] Unable to connect to the database. Retrying (1)... multiple times. By experience of seeing this message it could be a lot:

• Wrong credentials
• A bug in an entity definition
• An entity could not be found
• Something is wrong with a field in an entity
• Datatype in an entity is not support e.g. nvarchar is used on a Postgres DB`

You simply have no clue where to look.

In what way should I be able to see what actually goes wrong? How do you guys debug these errors? Thanks! :)

[basvdijk]

Looks like pull request #34 fixes this issue

[lancevo]

@basvdijk @kamilmysliwiec how do you handle connection error with TypeOrmModule? Do you have any code example? I want to be able to catch the error, and I couldn't find it in the documentation.
Thanks

[charmsRace]

I'm just running into that problem myself @lancevo. Currently, my app runs fine with a connection, but if I'm not on my company's VPN, my app can't get a DB connection and the whole thing crashes. Since I'm also using Nest to expose functionality independent of that DB, that's not ideal.

I'm presently sniffing around type definitions to figure out if there's a way to hook in an error handler, so I can let nest throw BadGatewayException (HTTP 502) or some other error. My client-side is already prepared to receive errors from API calls. You could maybe use @InjectConnection() except I'm not sure it could be called early enough.

Has anyone accomplished that before? I'm using TypeOrmModule::forRootAsync with useClass, in case that matters. So, since the whole configuration is just one plain object, I'm not sure where actual error-handling code could go.

[jaredmcateer]

I ran into this similar vague error

app | [Nest] 36   - 03/19/2019, 5:02 AM   [TypeOrmModule] Unable to connect to the database. Retrying (9)... +3018ms
app | Error: connect ENOENT 3306,
app |     at PipeConnectWrap.afterConnect [as oncomplete] (net.js:1097:14)
app |     --------------------
app |     at Protocol._enqueue (/opt/app/node_modules/mysql/lib/protocol/Protocol.js:144:48)
app |     at Protocol.handshake (/opt/app/node_modules/mysql/lib/protocol/Protocol.js:51:23)
app |     at PoolConnection.connect (/opt/app/node_modules/mysql/lib/Connection.js:118:18)
app |     at Pool.getConnection (/opt/app/node_modules/mysql/lib/Pool.js:48:16)
app |     at /opt/app/src/driver/mysql/MysqlDriver.ts:858:18
app |     at new Promise (<anonymous>)
app |     at MysqlDriver.createPool (/opt/app/src/driver/mysql/MysqlDriver.ts:855:16)
app |     at MysqlDriver.<anonymous> (/opt/app/src/driver/mysql/MysqlDriver.ts:326:36)
app |     at step (/opt/app/node_modules/tslib/tslib.js:133:27)
app |     at Object.next (/opt/app/node_modules/tslib/tslib.js:114:57)

I've been trying to get nest and typeorm working in docker containers and I incorrectly assumed that because nestjs supported an empty TypeOrmModule.forRoot() when the configuration is in a ormconfig.json file that it would also support the TYPEORM_ environment variables. I spent more time that I want to admit troubleshooting everything else before I tried hardcoding the values into the forRoot method.

[zmGitHub]

@jaredmcateer try set:

....
synchronize: false

[karanacharekar]

@lancevo @Calamitizer Were you'll able to achieve db connection error handling in nestjs ?

[charlie-harvey]

This is totally still happening. What am I missing here:

package.json

    "@nestjs/common": "^6.11.11",
    "@nestjs/core": "^6.11.11",
    "@nestjs/typeorm": "^6.3.3",
    "typeorm": "^0.2.24",

[NestWinston] error 2020-05-07T21:14:28.767Z [TypeOrmModule] Unable to connect to the database. Retrying (1)...
[NestWinston] error 2020-05-07T21:14:31.774Z [TypeOrmModule] Unable to connect to the database. Retrying (2)...

Real easy to replicate. I just turn off the database. When its on, everything is great. Picks up the entity files in the right folders and everything. If I move the entity files, it complains the right way. But it doesn't complain the right way when the database isn't there.

Is there some flag I could be setting somewhere? In NestJS? In TypeORM? Where does the "show me more logs" go?

Thanks.