nest: request property in a service class is undefined after v9.3.1
Is there an existing issue for this?
- I have searched the existing issues
Current behavior
I have a simple constrictor for a service class as following
constructor( @Inject(REQUEST) public readonly request: Request, runAuthDependincies: Boolean = true, )
after you had released v9.3.1 this request is undefined
Minimum reproduction code
https://codesandbox.io/s/withered-monad-zgg1nu
Steps to reproduce
just updating the packages to 9.3.1
Expected behavior
The request property should not be undefined as before
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
9.3.1
Packages versions
"@hapi/hapi": "^21.0.0",
"@hapi/joi": "^17.1.1",
"@nestjs-modules/mailer": "^1.8.1",
"@nestjs/common": "^9.0.0",
"@nestjs/config": "^2.2.0",
"@nestjs/core": "^9.0.0",
"@nestjs/jwt": "^9.0.0",
"@nestjs/passport": "^9.0.0",
"@nestjs/platform-express": "^9.0.0",
"apollo-server-express": "^3.11.1",
"apollo-server-plugin-base": "^3.7.1",
"class-transformer": "^0.5.1",
"class-validator": "^0.13.2",
"dotenv": "^16.0.3",
"googleapis": "^109.0.1",
"nodemailer": "^6.9.0",
"passport-google-oauth20": "^2.0.0",
"reflect-metadata": "^0.1.13",
"rimraf": "^3.0.2",
"rxjs": "^7.2.0"
Node.js version
16.3
In which operating systems have you tested?
- macOS
- Windows
- Linux
Other
No response
About this issue
- Original URL
- State: closed
- Created a year ago
- Reactions: 4
- Comments: 62 (45 by maintainers)
Right, will look at it as well as soon as I get some free time. Disappointed my first contribution broke stuff…
Having the same issue:
scope.REQUESThttps://codesandbox.io/p/sandbox/runtime-star-dpm9rv?file=%2Fsrc%2Fapp.module.ts&selection=[{"endColumn"%3A1%2C"endLineNumber"%3A11%2C"startColumn"%3A1%2C"startLineNumber"%3A11}]
Any tips on how I can help you refine this issue further from this point?
@kamilmysliwiec I will try and get automapper in my repro repo, and see if I can figure out what the issue is.
Any pipes with scope
REQUESTdoesnt work 👍🏻So I think I got to the bottom of it, and the PR #11041 has been updated. I’ve also added a diagram to explain the problem.
nope more investigation needed…
and I think I got a test reproducing the issue
this fails. It should return false.
@kamilmysliwiec @micalevisk
I think I found the possible problem, at least in our code base it seems to be with pipes as they are marked as
isTreeStatic = true. that obviously will return true when callingisDependencyTreeStatic()ininstance-wrapper: isDependencyTreeDurable -> introspectDepsAttribute()Adding
{scope: Scope.REQUEST}to the Pipe makes it work.our controller:
The fixed Pipe:
So, not sure if I need to guard against Pipes and treat them differently, I think I need to dig deeper.
@kamilmysliwiec @micalevisk just experienced the problem in our code base with nestjs 9.3.2 and we do not use AutoMapper.
mm that should be ok as the first
!isTreeNonDurableshould return false so the second should not even be consideredBut I’m still confused as I’ve now got a small app with a controller and a few different providers with different scopes (singleton, request, transient) and I cannot reproduce the issue…
I’ve done some really extensive digging/hacking (on my project, no NestJS internals) and removed almost everything from except for my printer controller and service. After that I went much further to delete almost everything that I could possibly delete or nullify from the dependencies. Still left with the error.
So far what I think is left is a TypeORM feature called Printer (entity), AutoMapper and the two-layer mixin extensions I use to provide the controller with CRUD operations.
With a fresh mind I should be able to port this into CodeSandbox. Cant promise it tho. Hope this helps.
@Durairaj that’s another one. Upgrade your
@nestjs/coreto 9.3@micalevisk so I’m guessing this might be related to this PR https://github.com/nestjs/nest/pull/10809 (perhaps
isDependencyTreeDurablereturns true even though the tree isn’t durable for some edge-case scenarios?ok got more understanding of the issue, I started commenting on the PR itself.
possible fix in the PR above
@vizio360 exactly. 9.3.2 doesn’t fix the bug introduced in 9.3.0
Correct, and we are not using
ContextIdStrategy, so it sounds like the same issue @davidzwa is having.@micalevisk note - I didn’t revert https://github.com/nestjs/nest/pull/10698 yet
I didn’t install it before
https://github.com/nestjs/nest/pull/11018 reverted. Now - not sure what we should do about this one https://github.com/nestjs/nest/pull/10698 - sounds like this issue only occurs when AutoMapper is included in the project?
https://www.npmjs.com/package/@automapper/nestjs https://github.com/nartc/mapper/tree/main
https://automapperts.netlify.app/
what does that pesky automapper do??? 😃
Removing AutoMapper has removed the problem, but I must be fair: I’ve no idea why AutoMapper would be a durable provider or a reason for causing the static check to fail.
Indeed, none of my services (or anything) follow the durable provider pattern described by https://docs.nestjs.com/fundamentals/injection-scopes#durable-providers
All is purely transient, singleton or request scoped.
What is interesting is that from the log @davidzwa provided the
PrinterControllerdoes get request scope initially (see first line of the log) and then it gets durable…@davidzwa could you check the dependencies chain of
PrinterFileControllerandPrinterControllerand list them out? What I’m interested in is the scopes of each injected dependency and their dependencies.Hopefully you don’t have too many 😃
Problem’s gone with your suggestion. (FYI: my post above was 9.3.1 ofcourse)
No more 'introspected as durable for the PrinterFileController nor PrinterController.
That tip is really nice! I think this extract might help you:
Before the listen call we see
PrinterController introspected as request-scoped, immediately after thelisten(...)call the logs showPrinterController introspected as durable. This is the function that prints that (just making sure that I follow what is happening): https://github.com/nestjs/nest/blob/a439cd9a4120526a95295691e1ebbbce95d64f90/packages/core/injector/instance-wrapper.ts#L255@davidzwa another thing you could do: define the env var
NEST_DEBUG=trueand see if you got occurrences of ‘durable’ in your logs@micalevisk in the 9.2.1 edition neither MiddlewareModule::bindHandler or MiddlewareModule::registerHandler function is being called (no breakpoints or console logs that I added seem to trigger in the transpiled js code of nestjs). These are the places your changes seem to reside. I might try 9.3.1 soon for comparison.
Im not in the position to share the repo. Will keep you posted if I have more info to share.
hi @davidzwa is there any chance to share your code in a private repository with me?
or maybe you can see what was done at PR #10809 (which is pretty small) and try to debug it locally yourself 😃
https://codesandbox.io/s/withered-monad-zgg1nu
I’ll say it one more time.
Please provide a minimum reproduction repository (Git repository/StackBlitz/CodeSandbox project).
why reproductions are required
Otherwise, please use our Discord channel (Support). We are using GitHub to track Bug Reports, Feature Requests, and Regressions.
here is my basic service class