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

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)

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).

my-db-service@2.0.59 /home/matt/w/MY-DB-Service-Bad
├─┬ @nestjs/axios@3.0.0
│ └── reflect-metadata@0.1.14 deduped
├─┬ @nestjs/common@10.3.1
│ └── reflect-metadata@0.1.14 deduped
├─┬ @nestjs/config@3.1.1
│ └── reflect-metadata@0.1.14 deduped
├─┬ @nestjs/core@10.3.1
│ └── reflect-metadata@0.1.14 deduped
├─┬ @nestjs/terminus@10.2.1
│ └── reflect-metadata@0.1.14 deduped
├─┬ @nestjs/typeorm@10.0.1
│ └── reflect-metadata@0.1.14 deduped
├─┬ my-api-paginate-library@2.0.0
│ ├─┬ @nestjs/common@10.0.4
│ │ └── reflect-metadata@0.1.13 deduped
│ ├─┬ @nestjs/graphql@12.0.7
│ │ ├─┬ @nestjs/mapped-types@2.0.2
│ │ │ └── reflect-metadata@0.1.14 deduped
│ │ └── reflect-metadata@0.1.14 deduped
│ └── reflect-metadata@0.1.13
├─┬ my-api-response-library@2.0.0
│ └── reflect-metadata@0.1.14 deduped
├─┬ my-nest-logging-library@2.0.0
│ └── reflect-metadata@0.1.14 deduped
├─┬ my-request-caching-library@2.0.0
│ └── reflect-metadata@0.1.14 deduped
├── reflect-metadata@0.1.14
└─┬ typeorm@0.3.20
  └── reflect-metadata@0.2.1

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…

https://github.com/rbuckton/reflect-metadata/commit/31dde5fba00afaea8c08bc9f13b186c069879566

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…

my-db-service@2.0.59 /home/matt/w/MY-DB-Service-Bad
├─┬ @nestjs/axios@3.0.0
│ └── reflect-metadata@0.1.14 deduped
├─┬ @nestjs/common@10.3.1
│ └── reflect-metadata@0.1.14 deduped
├─┬ @nestjs/config@3.1.1
│ └── reflect-metadata@0.1.14 deduped
├─┬ @nestjs/core@10.3.1
│ └── reflect-metadata@0.1.14 deduped
├─┬ @nestjs/terminus@10.2.1
│ └── reflect-metadata@0.1.14 deduped
├─┬ @nestjs/typeorm@10.0.1
│ └── reflect-metadata@0.1.14 deduped
├─┬ my-api-paginate-library@2.0.0
│ ├─┬ @nestjs/common@10.0.4
│ │ └── reflect-metadata@0.1.13 deduped
│ ├─┬ @nestjs/graphql@12.0.7
│ │ ├─┬ @nestjs/mapped-types@2.0.2
│ │ │ └── reflect-metadata@0.1.14 deduped
│ │ └── reflect-metadata@0.1.14 deduped
│ └── reflect-metadata@0.1.13
├─┬ my-api-response-library@2.0.0
│ └── reflect-metadata@0.1.14 deduped
├─┬ my-nest-logging-library@2.0.0
│ └── reflect-metadata@0.1.14 deduped
├─┬ my-request-caching-library@2.0.0
│ └── reflect-metadata@0.1.14 deduped
├── reflect-metadata@0.1.14
└─┬ typeorm@0.3.19
  └── reflect-metadata@0.1.14 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…

I can confirm what @SylvainSimon said. To fix this issue you need to explicitly set the version of reflect metadata to version ^0.2. Old versions of nest cli will put the version to ^0.1.13 which will break validation decorators (in my case @Body and @Query were ignored). Setting the versions of nest core libraries to ^10.3.2 won’t work either (suggested from @micalevisk link from the last comment)

// ignored when 'reflect-metadata' is still on 0.1.13
"@nestjs/common": "^10.3.2",
"@nestjs/core": "^10.3.2",
// works with any nestjs core lib
"reflect-metadata": "^0.2.0",

If you upgrade your nest cli to the latest version with npm i -g @nestjs/cli you will get the latest version of ‘reflect-metadata’ and so you won’t encounter this issue anymore.

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 😃

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.

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

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: https://github.com/rbuckton/reflect-metadata/commit/31dde5fba00afaea8c08bc9f13b186c069879566

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

let’s do it again:

git clone git@github.com: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":"foo@bar.com","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":"foo@bar.com","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 😃

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.