Nest fastify middleware not trigger

[SirReiva]

Is there an existing issue for this?

• I have searched the existing issues

Current behavior

Updating nestjs from 8.0.9 to 8.0.10, with fastify platform([email protected]). Middleware not trigger but controller send response correctly.

Minimum reproduction code

https://github.com/SirReiva/nestjs-issue-fastify

Steps to reproduce

npm i
npm run start:dev

GET request to http://localhost:3000/rest/profiles/098fbb95-2082-493f-b0dd-0e72517bbea2

Expected behavior

Get log inside middleware

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

No response

NestJS version

8.0.9 -> 8.0.10

Packages versions

"@nestjs/common": "^8.0.10",
"@nestjs/core": "^8.0.0",
"@nestjs/platform-express": "^8.0.10",
"@nestjs/platform-fastify": "^8.0.10",
"reflect-metadata": "^0.1.13",
"rimraf": "^3.0.2",
"rxjs": "^7.2.0"

Node.js version

v14.17.5

In which operating systems have you tested?

• macOS
• Windows
• Linux

Other

No response

[kamilmysliwiec]

This should be fixed in 8.0.11

[thomaschaaf]

@kamilmysliwiec according to this comment this fix was reverted could you check? iamolegga/nestjs-pino#546 (comment)

[aikin-vip]

is there any progress ？

[adworacz]

I just ran into this issue as well with nestjs-pino, where my log statements emitted inside controllers/services do not have any corresponding request information.

[jmcdo29]

@adworacz @thomaschaaf @aikin-vip do one of y'all want to provide a minimum reproduction rather than just say you're also having an issue?

[B4nan]

I can confirm there are some weird issues in nest/fastify combo with latest versions too. In MikroORM we depend on contexts created via middlewares, and with nest/fastify POST requests are not executed inside middleware, or better say the async context created by middleware is broken on the way. v4 works because it uses domain API instead of async local storage. Alternatively using nestjs request scopes also work, but the most convenient way via ALS is not. With nest/express it works just fine, so it has to be something in the middleware support in fastify (that is some 3rd party plugin, right?).

I will try to create some reproductions for this when I have some time. But given I am not using nest myself anymore, and given I have shitload of work with maintaining MikroORM on its own, I was kinda waiting for others to chip in :D But more and more people are now blaming MikroORM, so I guess I will need to step in, as the bug is (almost certainly) not on our end.

Right now I can offer one repro from MikroORM users (havent check that one fully, the other that I used for debugging is unfortunately already removed by the owner, but I still got it locally):

https://github.com/romainbrancourt/mikroorm-nest-v5

The other is in the https://github.com/mikro-orm/nestjs-realworld-example-app/tree/v5, where I had to register the middleware manually to make things work. In that project I believe the post requests are working, but there is a different problem - order of middlewares is not stable, due to which the MikroORM middleware can be created after the profile one.

In general MikroORM v5 does validate we have clear context, so basically it validates that the middleware it registers was executed and that the async context is not broken/lost. With nest/express it works, with nest/fastify it does not. I believe there are actually 2 problems, one is order of middlewares, the other loosing of async context.

[adworacz]

@jmcdo29 Fair enough - I'd actually thought that the original repo was enough to reproduce the issue, but it appears to have been deleted, which I didn't expect.

I'll try putting a repo together once I get a spare moment, unless someone beats me to it.

[jmcdo29]

@adworacz @B4nan @aikin-vip @thomaschaaf I've created a new issue #8837 with a minimum reproduction. Could someone check the min repro and verify that this is the behavior you're noticing as a bug. Namely that req.customProp doesn't get populated with the FastifyAdapter but it does with the ExpressAdapter.