Injected @Body in POST request handler is `undefined` #13107

fdbatista · 2024-01-28T17:10:48Z

Is there an existing issue for this?

I have searched the existing issues

Current behavior

Hello.

I am trying to apply validations to a request, following the official docs.
This is the request I try to send. Content-Type header is application/json:

I have a middleware that captures correctly the parameters:

However, when the request reaches its controller function, the body is empty:

This is my bootstrap function:

async function bootstrap() {
  const app = await NestFactory.create(AppModule);

  app.enableVersioning({
    type: VersioningType.URI,
  });

  app.useGlobalPipes(
    new ValidationPipe({
      transform: true,
    }),
  );

  await app.listen(3000);
}

If I remove completely the payload, the request still hits the controller, which means it is bypassing the validation rules, which are the exact same as the ones from the official docs:

export class LoginDto {
  @IsEmail()
  email: string;

  @IsNotEmpty()
  password: string;
}

I organized the controllers into custom folders by module, so this controller is located under src\modules\auth.

Any ideas why this could be happening?
Thanks.

Minimum reproduction code

https://github.com/ahk-reminder/backend

Steps to reproduce

No response

Expected behavior

The controller function should receive a valid payload.

Package

Other package

No response

NestJS version

No response

Packages versions

{
"dependencies": {
    "@nestjs/common": "^10.0.0",
    "@nestjs/config": "^3.1.1",
    "@nestjs/core": "^10.0.0",
    "@nestjs/platform-express": "^10.0.0",
    "@nestjs/typeorm": "^10.0.1",
    "body-parser": "^1.20.2",
    "class-transformer": "^0.5.1",
    "class-validator": "^0.14.1",
    "mysql2": "^3.9.0",
    "reflect-metadata": "^0.1.13",
    "rxjs": "^7.8.1",
    "typeorm": "^0.3.20"
  },
  "devDependencies": {
    "@nestjs/cli": "^10.0.0",
    "@nestjs/schematics": "^10.0.0",
    "@nestjs/testing": "^10.3.1",
    "@types/express": "^4.17.21",
    "@types/jest": "^29.5.2",
    "@types/node": "^20.3.1",
    "@types/supertest": "^6.0.0",
    "@typescript-eslint/eslint-plugin": "^6.0.0",
    "@typescript-eslint/parser": "^6.0.0",
    "eslint": "^8.42.0",
    "eslint-config-prettier": "^9.0.0",
    "eslint-plugin-prettier": "^5.0.0",
    "jest": "^29.5.0",
    "prettier": "^3.0.0",
    "source-map-support": "^0.5.21",
    "supertest": "^6.3.3",
    "ts-jest": "^29.1.0",
    "ts-loader": "^9.4.3",
    "tsconfig-paths": "^4.2.0",
    "typescript": "^5.1.3"
  },
}

Node.js version

v20.9.0

In which operating systems have you tested?

macOS
Windows
Linux

Other

No response

The text was updated successfully, but these errors were encountered:

fdbatista · 2024-01-28T17:28:11Z

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.

fdbatista · 2024-01-28T18:32:19Z

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.

micalevisk · 2024-01-28T19:44:35Z

looks like your repository is private

fdbatista · 2024-01-28T20:01:03Z

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.

micalevisk · 2024-01-28T20:10:10Z

after doing

curl "http://localhost:3000/v1/auth/login" -X POST -H 'content-type: application/json' --data '{"email":"foo@bar.com","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 · 2024-01-28T20:27:25Z

Yeap.

after doing
curl "http://localhost:3000/v1/auth/login" -X POST -H 'content-type: application/json' --data '{"email":"foo@bar.com","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 · 2024-01-28T20:34:17Z

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.

fdbatista · 2024-01-28T21:03:20Z

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

mattezell · 2024-01-30T20:56:20Z

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 ?

mattezell · 2024-01-31T20:59:58Z

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 · 2024-02-01T12:38:22Z

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

mattezell · 2024-02-01T13:46:59Z

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

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

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

kamilmysliwiec · 2024-02-07T09:38:55Z

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)

kamilmysliwiec · 2024-02-07T09:56:02Z

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)

micalevisk · 2024-02-08T15:03:40Z

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

SylvainSimon · 2024-02-08T19:42:00Z

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

danbaghilovici · 2024-02-25T10:05:12Z

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.

fdbatista added the needs triage This issue has not been looked into label Jan 28, 2024

fdbatista closed this as completed Jan 28, 2024

fdbatista reopened this Jan 28, 2024

micalevisk closed this as not planned Won't fix, can't repro, duplicate, stale Jan 28, 2024

kamilmysliwiec mentioned this issue Feb 1, 2024

Fastify with TypeORM with @Body() undefined #13146

Closed

15 tasks

micalevisk reopened this Feb 1, 2024

micalevisk added type: bug 😭 and removed needs triage This issue has not been looked into labels Feb 1, 2024

This was referenced Feb 1, 2024

typeorm: 0.3.20 introduces issues with @ApiProperty on some DTOs nestjs/swagger#2811

Closed

0.3.20 regression with NestJS, TypeORM and Swagger typeorm/typeorm#10671

Open

micalevisk mentioned this issue Feb 5, 2024

AppController query, req, res variables are undefined when typegoose's setLoglevel executed in main.ts #13163

Closed

15 tasks

kamilmysliwiec mentioned this issue Feb 7, 2024

Incompatibility between latest @nestjs/swagger 7.2.0 and @nestjs/typeorm 10.0.1 due to reflect-metadata nestjs/swagger#2821

Closed

4 tasks

micalevisk closed this as completed Feb 8, 2024

danbaghilovici mentioned this issue Feb 26, 2024

Validation Pipe is not executed #13260

Closed

15 tasks

nestjs locked and limited conversation to collaborators Feb 26, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Injected @Body in POST request handler is `undefined` #13107

Injected @Body in POST request handler is `undefined` #13107

fdbatista commented Jan 28, 2024

fdbatista commented Jan 28, 2024

fdbatista commented Jan 28, 2024 •

edited

Loading

micalevisk commented Jan 28, 2024

fdbatista commented Jan 28, 2024 •

edited

Loading

micalevisk commented Jan 28, 2024 •

edited

Loading

fdbatista commented Jan 28, 2024

micalevisk commented Jan 28, 2024

fdbatista commented Jan 28, 2024

mattezell commented Jan 30, 2024

mattezell commented Jan 31, 2024 •

edited

Loading

micalevisk commented Feb 1, 2024

mattezell commented Feb 1, 2024

kamilmysliwiec commented Feb 7, 2024

kamilmysliwiec commented Feb 7, 2024

micalevisk commented Feb 8, 2024

SylvainSimon commented Feb 8, 2024

danbaghilovici commented Feb 25, 2024

Injected @Body in POST request handler is undefined #13107

Injected @Body in POST request handler is undefined #13107

Comments

fdbatista commented Jan 28, 2024

Is there an existing issue for this?

Current behavior

Minimum reproduction code

Steps to reproduce

Expected behavior

Package

Other package

NestJS version

Packages versions

Node.js version

In which operating systems have you tested?

Other

fdbatista commented Jan 28, 2024

fdbatista commented Jan 28, 2024 • edited Loading

micalevisk commented Jan 28, 2024

fdbatista commented Jan 28, 2024 • edited Loading

micalevisk commented Jan 28, 2024 • edited Loading

fdbatista commented Jan 28, 2024

micalevisk commented Jan 28, 2024

fdbatista commented Jan 28, 2024

mattezell commented Jan 30, 2024

mattezell commented Jan 31, 2024 • edited Loading

micalevisk commented Feb 1, 2024

mattezell commented Feb 1, 2024

kamilmysliwiec commented Feb 7, 2024

kamilmysliwiec commented Feb 7, 2024

micalevisk commented Feb 8, 2024

SylvainSimon commented Feb 8, 2024

danbaghilovici commented Feb 25, 2024

Injected @Body in POST request handler is `undefined` #13107

Injected @Body in POST request handler is `undefined` #13107

fdbatista commented Jan 28, 2024 •

edited

Loading

fdbatista commented Jan 28, 2024 •

edited

Loading

micalevisk commented Jan 28, 2024 •

edited

Loading

mattezell commented Jan 31, 2024 •

edited

Loading