felanios / murlock

MurLock: A distributed locking solution for NestJS, providing a decorator for critical sections with Redis-based synchronization. Ideal for microservices and scalable applications.
https://www.npmjs.com/package/murlock
MIT License
62 stars 1 forks source link

According to the document configuration, an error will be reported #8

Closed jiuxiangyangguang closed 9 months ago

jiuxiangyangguang commented 11 months ago

Snipaste_2023-09-27_16-21-19

felanios commented 11 months ago

Hi, did you use MurLockService directly or decorator?

OsoianMarcel commented 9 months ago

I have exactly the same problem.

Steps to reproduce:

  1. Install the package "murlock" (the dependencies are already installed).
  2. Add "MurLockModule" in app.module imports (sync or async does not matter).
  3. Start the app and watch the console.
[Nest] 50  - 11/03/2023, 3:14:30 PM     LOG [NestFactory] Starting Nest application...
[Nest] 50  - 11/03/2023, 3:14:30 PM     LOG [InstanceLoader] MongooseModule dependencies initialized +1ms
[Nest] 50  - 11/03/2023, 3:14:30 PM   ERROR [ExceptionHandler] Nest can't resolve dependencies of the ClsModule (?, ModuleRef). Please make sure that the argument HttpAdapterHost at index [0] is available in the ClsModule context.

Potential solutions:
- Is ClsModule a valid NestJS module?
- If HttpAdapterHost is a provider, is it part of the current ClsModule?
- If HttpAdapterHost is exported from a separate @Module, is that module imported within ClsModule?
  @Module({
    imports: [ /* the Module containing HttpAdapterHost */ ]
  })

Error: Nest can't resolve dependencies of the ClsModule (?, ModuleRef). Please make sure that the argument HttpAdapterHost at index [0] is available in the ClsModule context.

Potential solutions:
- Is ClsModule a valid NestJS module?
- If HttpAdapterHost is a provider, is it part of the current ClsModule?
- If HttpAdapterHost is exported from a separate @Module, is that module imported within ClsModule?
  @Module({
    imports: [ /* the Module containing HttpAdapterHost */ ]
  })

    at Injector.lookupComponentInParentModules (/home/node/app/node_modules/@nestjs/core/injector/injector.js:254:19)
    at processTicksAndRejections (node:internal/process/task_queues:95:5)
    at Injector.resolveComponentInstance (/home/node/app/node_modules/@nestjs/core/injector/injector.js:207:33)
    at resolveParam (/home/node/app/node_modules/@nestjs/core/injector/injector.js:128:38)
    at async Promise.all (index 0)
    at Injector.resolveConstructorParams (/home/node/app/node_modules/@nestjs/core/injector/injector.js:143:27)
    at Injector.loadInstance (/home/node/app/node_modules/@nestjs/core/injector/injector.js:70:13)
    at Injector.loadProvider (/home/node/app/node_modules/@nestjs/core/injector/injector.js:97:9)
    at /home/node/app/node_modules/@nestjs/core/injector/instance-loader.js:56:13
    at async Promise.all (index 0)

FYI: Downgrading to the version 1.2.1 did not help.

I like the library, please fix ASAP. Thank you.

felanios commented 9 months ago

Hi @OsoianMarcel thank you for feedback, I'll release a fix for this problem immediately.

felanios commented 9 months ago

Hi @OsoianMarcel Which package manager did you use, also can you provide of @nestjs/... packages versions?

felanios commented 9 months ago

@jiuxiangyangguang @OsoianMarcel Hi again, I published beta version for this issue, npm i murlock@2.0.0-beta.1 can you try again with this version?

OsoianMarcel commented 9 months ago

package manager: yarn v1.22.19 environment: docker image node:20-alpine node version: v20.9.0

"dependencies": {
    "@nestjs/cache-manager": "^2.1.0",
    "@nestjs/common": "^10.0.0",
    "@nestjs/config": "^3.1.1",
    "@nestjs/core": "^10.0.0",
    "@nestjs/mongoose": "^10.0.1",
    "@nestjs/platform-express": "^10.0.0",
    "@nestjs/swagger": "^7.1.13",
    "@willsoto/nestjs-prometheus": "^6.0.0",
    "axios": "^1.5.1",
    "cache-manager": "^5.2.4",
    "cache-manager-redis-yet": "^4.1.2",
    "class-transformer": "^0.5.1",
    "class-validator": "^0.14.0",
    "moment": "^2.29.4",
    "mongoose": "^8.0.0",
    "murlock": "2.0.0-beta.1",
    "nestjs-pino": "^3.5.0",
    "object-hash": "^3.0.0",
    "pino-http": "^8.5.0",
    "pino-pretty": "^10.2.3",
    "prom-client": "^15.0.0",
    "redis": "^4.6.10",
    "reflect-metadata": "^0.1.13",
    "rxjs": "^7.8.1"
  },
  "devDependencies": {
    "@nestjs/cli": "^10.0.0",
    "@nestjs/schematics": "^10.0.0",
    "@nestjs/testing": "^10.0.0",
    "@types/express": "^4.17.17",
    "@types/jest": "^29.5.2",
    "@types/node": "^20.3.1",
    "@types/object-hash": "^3.0.5",
    "@types/supertest": "^2.0.12",
    "@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",
    "madge": "^6.1.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",
    "ts-node": "^10.9.1",
    "tsconfig-paths": "^4.2.0",
    "typescript": "^5.1.3"
  }

I am also using 3 private NPM packages (nothing special).

I tried to use version 2.0.0-beta.1, but unfortunately, the result is the same.

[Nest] 64  - 11/04/2023, 12:05:02 PM     LOG [NestFactory] Starting Nest application...
[Nest] 64  - 11/04/2023, 12:05:02 PM     LOG [InstanceLoader] MongooseModule dependencies initialized +2ms
[Nest] 64  - 11/04/2023, 12:05:02 PM   ERROR [ExceptionHandler] Nest can't resolve dependencies of the ClsModule (?, ModuleRef). Please make sure that the argument HttpAdapterHost at index [0] is available in the ClsModule context.

Potential solutions:
- Is ClsModule a valid NestJS module?
- If HttpAdapterHost is a provider, is it part of the current ClsModule?
- If HttpAdapterHost is exported from a separate @Module, is that module imported within ClsModule?
  @Module({
    imports: [ /* the Module containing HttpAdapterHost */ ]
  })

Error: Nest can't resolve dependencies of the ClsModule (?, ModuleRef). Please make sure that the argument HttpAdapterHost at index [0] is available in the ClsModule context.

Potential solutions:
- Is ClsModule a valid NestJS module?
- If HttpAdapterHost is a provider, is it part of the current ClsModule?
- If HttpAdapterHost is exported from a separate @Module, is that module imported within ClsModule?
  @Module({
    imports: [ /* the Module containing HttpAdapterHost */ ]
  })

    at Injector.lookupComponentInParentModules (/home/node/app/node_modules/@nestjs/core/injector/injector.js:254:19)
    at processTicksAndRejections (node:internal/process/task_queues:95:5)
    at Injector.resolveComponentInstance (/home/node/app/node_modules/@nestjs/core/injector/injector.js:207:33)
    at resolveParam (/home/node/app/node_modules/@nestjs/core/injector/injector.js:128:38)
    at async Promise.all (index 0)
    at Injector.resolveConstructorParams (/home/node/app/node_modules/@nestjs/core/injector/injector.js:143:27)
    at Injector.loadInstance (/home/node/app/node_modules/@nestjs/core/injector/injector.js:70:13)
    at Injector.loadProvider (/home/node/app/node_modules/@nestjs/core/injector/injector.js:97:9)
    at /home/node/app/node_modules/@nestjs/core/injector/instance-loader.js:56:13
    at async Promise.all (index 0)
felanios commented 9 months ago

https://github.com/Papooch/nestjs-cls/issues/77#issuecomment-1632649914 As I guessed, this is actually due to the difference in @nestjs/... versions, so nestjs's dependency injection mechanism cannot solve it. I published the package with npm and I have a project where I use pnpm, I had the same problem there before the beta was released. The problem was solved when I updated the peerDependencies and increased the NestJS versions in the project. @OsoianMarcel Can you try with these versions? "peerDependencies": { "@nestjs/common": ">=10.0.5", "@nestjs/core": ">=10.0.5" },

OsoianMarcel commented 9 months ago

You are right, deleting of the lock file and reinstalling of the packages fixed the problem. I had a mismatch between the packages (my bad).

But now I have another problem: MurLock Redis Client Error: Redis connection to 127.0.0.1:6379 failed - connect ECONNREFUSED 127.0.0.1:6379

Import of the module:

MurLockModule.registerAsync({
      inject: [ConfigService],
      useFactory: async (
        config: ConfigService<AppEnvVars, true>,
      ): Promise<MurLockModuleOptions> => ({
        redisOptions: { url: config.get('REDIS_URL') },
        wait: 1e3,
        maxAttempts: 10,
        logLevel:
          config.get('NODE_ENV') === AppEnvironment.PRODUCTION
            ? 'log'
            : 'debug',
      }),
    })

The problem may be the peer dependency of Redis package version. I am using the major version 4, but your library seems to use the package version 3.

Looks like the url prop. provided in config is ignored. Because the URL I provide has a different dns name (not 127.0.0.1)

felanios commented 9 months ago

@OsoianMarcel Actually I migrated redis v3 to v4 in beta version. Can you provide REDIS_URL the localhost one.

OsoianMarcel commented 9 months ago

@OsoianMarcel Actually I migrated redis v3 to v4 in beta version. Can you provide REDIS_URL the localhost one.

thanks, the beta version works just fine. I hope I'll see soon a release with major version 2 (with redis v4). Thank you!!!

FYI: I can not provide localhost because my project works inside docker, so the redis service lives under docker DNS name "redis".

OsoianMarcel commented 9 months ago

+1 ⭐ In my opinion the issue can be closed.

felanios commented 9 months ago

@OsoianMarcel Thanks for your support, v2 will be released soon.