Injected @Body in POST request handler is `undefined` about nest

[mattezell]

Thanks @micalevisk

So I've been back at it again this morning, doing a bit more diagnostics.

First off, apologies for any thrashing or confusion that I've introduced in my investigation... Hunting down dependency conflicts of dependency's dependencies is enough to make your head spin...

That said, I should have likely began my investigation by running an 'npm ls reflect-metadata' since I was pretty certain this is where the breakdown with populating our controller method's arg was happening.

I don't believe this is actually a problem with the latest release of NestJS itself - and instead was introduced to our project as a result of typeorm being a top level dependency in our project (before my time, so not sure why it was added, though I suspect it can be removed).

With typeorm as a top level dep in our project, and with it being ref'd via the ^, typeorm upgraded to 0.3.20 on a clean install (no package-lock.json), which resulted in a different, and apparently conflicting, version of reflect-metadata was also introduced (see ls output).

[email protected] /home/matt/w/MY-DB-Service-Bad
├─┬ @nestjs/[email protected]
│ └── [email protected] deduped
├─┬ @nestjs/[email protected]
│ └── [email protected] deduped
├─┬ @nestjs/[email protected]
│ └── [email protected] deduped
├─┬ @nestjs/[email protected]
│ └── [email protected] deduped
├─┬ @nestjs/[email protected]
│ └── [email protected] deduped
├─┬ @nestjs/[email protected]
│ └── [email protected] deduped
├─┬ [email protected]
│ ├─┬ @nestjs/[email protected]
│ │ └── [email protected] deduped
│ ├─┬ @nestjs/[email protected]
│ │ ├─┬ @nestjs/[email protected]
│ │ │ └── [email protected] deduped
│ │ └── [email protected] deduped
│ └── [email protected]
├─┬ [email protected]
│ └── [email protected] deduped
├─┬ [email protected]
│ └── [email protected] deduped
├─┬ [email protected]
│ └── [email protected] deduped
├── [email protected]
└─┬ [email protected]
  └── [email protected]

So in walking through with the debugger, I initially saw the top level node_modules/reflect-metadata/Reflect.js as being in play, and so incorrectly associated the issue with the recent upgrade to NestJS... But when digging in further this morning, I noticed that later down the chain, the 0.2.1 nested instance somehow assumed control from /node_modules/typeorm/node_modules/reflect-metadata/...

Apparently, this newer version of 0.2.1 introduces some notion of a Metadata Provider and Registry in order to support multiple imported version of reflect-metadata - which seemingly did the opposite of that in the case of our project, resulting in Nest.js no longer properly populating the controller method's @Body decorated arg...

rbuckton/reflect-metadata@31dde5f

By setting our top level reference of typeorm to the specific "0.3.19" version, which was the release immediately preceding their bump of reflect-metadata to 0.2.1... Now with the top level typeorm using 0.1.14 (deuped, so actually 0.1.13), all is well in our world..

[email protected] /home/matt/w/MY-DB-Service-Bad
├─┬ @nestjs/[email protected]
│ └── [email protected] deduped
├─┬ @nestjs/[email protected]
│ └── [email protected] deduped
├─┬ @nestjs/[email protected]
│ └── [email protected] deduped
├─┬ @nestjs/[email protected]
│ └── [email protected] deduped
├─┬ @nestjs/[email protected]
│ └── [email protected] deduped
├─┬ @nestjs/[email protected]
│ └── [email protected] deduped
├─┬ [email protected]
│ ├─┬ @nestjs/[email protected]
│ │ └── [email protected] deduped
│ ├─┬ @nestjs/[email protected]
│ │ ├─┬ @nestjs/[email protected]
│ │ │ └── [email protected] deduped
│ │ └── [email protected] deduped
│ └── [email protected]
├─┬ [email protected]
│ └── [email protected] deduped
├─┬ [email protected]
│ └── [email protected] deduped
├─┬ [email protected]
│ └── [email protected] deduped
├── [email protected]
└─┬ [email protected]
  └── [email protected] deduped

Now that the fire is out, I will look into if there's any reason for us to have typeorm as a direct import, since we are leveraging @nestjs/typeorm (I'm suspecting not based on a quick test by generating a new NestJS project and adding @nestjs/typeorm working as expected without a top level import).

Thanks for the attention on this - hoping this helps someone else who might stumble here from a similar issue...

[kamilmysliwiec]

This should be fixed in 10.3.2 (reflect-metadata v0.2 is now allowed which should lead to package managers using a deduped version of the package)

[SylvainSimon]

I am allowing myself to comment in this ticket. I'm using NestJS as a websocket server with socket.io

The decorators of the event methods (eg: @MessageBody()) are completely ignored if reflect-metadata is not updated to 0.2 when switching to NestJS 10. Everything worked fine in 9 and suddenly my decorators no longer had any kind of importance

Two days wasted.. If it can help anyone :)

[fdbatista]

Really weird stuff happening here.
As soon as I renamed the new module to auth, @Body stopped working again.
So I had to give up and name the module authentication until I figure out why it's happening.

[fdbatista]

looks like your repository is private

@micalevisk Yes, sorry. Just updated its visibility
I am building this from the ground up as an exercise to learn NestJS.
If u take a look at it, please note that I removed the problematic auth module, so right now, to reproduce the issue, you'd have to rename the authentication one back to auth.

[fdbatista]

let's do it again:

git clone [email protected]:ahk-reminder/backend.git
cd backend
## then remove the `TypeOrmModule.forRootAsync` from `AppModule` because it shouldn't be needed in order to reproduce this issue. 
## then add a console.log at src/modules/authentication/authentication.controller.ts
npm i
npm start

curl "http://localhost:3000/v1/auth/login" -X POST -H 'content-type: application/json' --data '{"email":"[email protected]","password":"bar"}'
# got a 404, as expected since there's no route registered in this 'auth' path

curl "http://localhost:3000/v1/authentication/login" -X POST -H 'content-type: application/json' --data '{"email":"[email protected]","password":"bar"}'
# works as expected

please edit your repro to reproduce the issue you're reporting. Everything looks fine so far.

Nevermind. It works with the current setup, so thanks for keeping track :)

[mattezell]

This appears to be related to the version bump of reflect-metadata in 10.3.0, where reflect-metadata was changed from 0.1.13 to 0.1.14.

0.1.14 introduced the following change that is causing this issue in our project: rbuckton/reflect-metadata@31dde5f

Specifically, changes to OrdinaryHasOwnMetadata, which is now calling a new GetMetadataProvider method that behaves differently than the previous GetOrCreateMetadataMap method.

[micalevisk]

let's make this open until we fix that reflect-metadata thing, to avoid new issues

[fdbatista]

I just added a new module, service and controller, and requests just work.
So I guess I will just replace the buggy one with this newly-added and that's it.

Closing.

[micalevisk]

looks like your repository is private

[micalevisk]

after doing

curl "http://localhost:3000/v1/auth/login" -X POST -H 'content-type: application/json' --data '{"email":"[email protected]","password":"bar"}'

and with a console.log({loginDto}) at AuthenticationController#login

I got this output on my terminal:

which is expected, right? the JSON body was parsed to object

[fdbatista]

Yeap.

after doing

curl "http://localhost:3000/v1/auth/login" -X POST -H 'content-type: application/json' --data '{"email":"[email protected]","password":"bar"}'

and with a console.log({loginDto}) at AuthenticationController#login

I got this output on my terminal:

which is expected, right? the JSON body was parsed to object

Yes, that is correct.
But if I rename the authorization module, service and controller to just auth it fails.

[micalevisk]

let's do it again:

git clone [email protected]:ahk-reminder/backend.git
cd backend
## then remove the `TypeOrmModule.forRootAsync` from `AppModule` because it shouldn't be needed in order to reproduce this issue. 
## then add a console.log at src/modules/authentication/authentication.controller.ts
npm i
npm start

curl "http://localhost:3000/v1/auth/login" -X POST -H 'content-type: application/json' --data '{"email":"[email protected]","password":"bar"}'
# got a 404, as expected since there's no route registered in this 'auth' path

curl "http://localhost:3000/v1/authentication/login" -X POST -H 'content-type: application/json' --data '{"email":"[email protected]","password":"bar"}'
# works as expected

please edit your repro to reproduce the issue you're reporting. Everything looks fine so far.

[mattezell]

I'm still trying to trace this, but we're now having the same issue as originally reported in one of our long running Nestjs APIs...

Due to org changes, our CI/CD pipeline removes the pacakge-lock.json - at which time 10.3.1 versions of various @nestjs libs began resolving on npm install.

One of our long working controllers now reports that it can't read a property of undefined when accessing the body - and when we inspect "@Body rb" in the controller, it is undefined...

In my debugging this afternoon, I see that we're landing here before hitting our controller without the expected body object:

nest/packages/core/interceptors/interceptors-consumer.ts

Line 23 in 4818900

return next();

If I revert back to a 10.0.5, everything behaves as expected...

Any ideas @kamilmysliwiec ?

[kamilmysliwiec]

I left a comment on this in the typeorm repository here typeorm/typeorm#10671 (comment)

I believe this PR should fix this issue #12943 (updating the peer dependency constraint making it OK to use v0.2 and share it with other packages)

[micalevisk]

seems to be fixed typeorm/typeorm#10671 (comment)