Middleware not applied when using setGlobalPrefix

[mentos1386]

Is there an existing issue for this?

• I have searched the existing issues

Current behavior

I have an app which uses setGlobalPrefix('api') and then i have a module (non-root) which sets a middleware forRoutes('*').

I would expect the middleware to act on all routes. But it doesn't.

Minimum reproduction code

https://github.com/mentos1386/nestjs-observability/tree/e84c0b92be9416c0d29255007f3a107f6d0d900c

Steps to reproduce

1. npm ci
2. npx nx serve example
3. curl http://localhost:3000/api
4. Observe that there is no "YOU SHOULD SEE ME" in console.
5. Edit example/src/main.ts and comment out line 17.
6. curl http://localhost:3000
7. Observe that there is now "YOU SHOULD SEE ME" in console.

Expected behavior

I would expect the middleware to act on all routes. But it doesn't.

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

Packages versions

[System Information]
OS Version     : Linux 6.3
NodeJS Version : v20.0.0
NPM Version    : 8.19.4

[Nest CLI]
Nest CLI Version : 9.4.2

[Nest Platform Information]
platform-express version : 9.4.0
schematics version       : 9.1.0
testing version          : 9.4.0
common version           : 9.4.0
core version             : 9.4.0

Node.js version

20.0.0

In which operating systems have you tested?

• macOS
• Windows
• Linux

Other

No response

[linkFly6]

I also encountered this problem. Has this problem solved?

[micalevisk]

@linkFly6 this GH Issue is still open, so no.

I didn't investigate it further yet. Feel free to do so.

[kamilmysliwiec]

Please provide a minimum reproduction repository (Git repository/StackBlitz/CodeSandbox project).

[mentos1386]

@kamilmysliwiec it's in the PR description. Is it not minimal enough?

[kamilmysliwiec]

Description != minimum reproduction repository

[mentos1386]

I meant the following:

Minimum reproduction code:

https://github.com/mentos1386/nestjs-observability/tree/e84c0b92be9416c0d29255007f3a107f6d0d900c

Steps to reproduce:

1. npm ci
2. npx nx serve example
3. curl http://localhost:3000/api
4. Observe that there is no "YOU SHOULD SEE ME" in console.
5. Edit example/src/main.ts and comment out line 17.
6. curl http://localhost:3000
7. Observe that there is now "YOU SHOULD SEE ME" in console.

[kamilmysliwiec]

Can you provide a minimum(!!) reproduction repository? (see instructions under this link but long story short, no extra libs, irrelevant dependencies, Nx, etc)

[crice88]

Not sure if this will help any. I did notice a change where I had excluded routes that contained the globalPrefix i/e api/cats. In v9.0.0 this worked fine, after upgrading to v9.4.2 my routes were no longer being filtered. Removing the prefix from the excluded routes solved my issue i/e cats.

[ealmansi]

I can confirm the bug is happening in both Nest 9.x and 10.x

Here's a minimum reproduction repo: https://stackblitz.com/edit/nestjs-11572?file=src%2Fmain.ts

Steps to reproduce:

1. Open the link above and wait until app is fully up and running.
2. Verify that the message "Running MyMiddleware.use" is displayed every time you visit the app.
3. Uncomment line 57 and restart the app.
4. Edit the app URL to ensure that you're visiting the route "/api".
5. Verify that the message is no longer displayed when you visit the app.

[ealmansi]

After some investigation, I believe that the issue comes from how the middleware path is being generated from the route info object. Take a look at this test:

// packages/core/test/middleware/route-info-path-extractor.spec.ts
      Reflect.set(routeInfoPathExtractor, 'prefixPath', '/api');

      expect(
        routeInfoPathExtractor.extractPathsFrom({
          path: '*',
          method: RequestMethod.ALL,
        }),
      ).to.eql(['/api/*']);

The test is saying: if the global prefix is /api, and the path is *, then the middleware route should be /api/*.

However, this pattern does not match the root route /api - which in turn is causing this bug. If you actually visit the route /api/, the middleware gets executed again.

It would be simple enough to update extractPathsFrom such that it no longer adds that slash in the middle, but given that there's a quite a few tests for the RouteInfoPathExtractor depending on this behaviour, I'm not sure whether this is a bug or a feature.

[CodyTseng]

This may be a bug I wrote, I will try to fix it ASAP