Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix(microservices): fix rabbitmq no-assert not being applied correctly #13285

Merged
merged 1 commit into from
Mar 17, 2024
Merged

fix(microservices): fix rabbitmq no-assert not being applied correctly #13285

merged 1 commit into from
Mar 17, 2024

Conversation

sorooshme
Copy link
Contributor

@sorooshme sorooshme commented Mar 2, 2024

PR Checklist

Please check if your PR fulfills the following requirements:

PR Type

What kind of change does this PR introduce?

  • Bugfix
  • Feature
  • Code style update (formatting, local variables)
  • Refactoring (no functional changes, no api changes)
  • Build related changes
  • CI related changes
  • Other... Please describe:

What is the current behavior?

The noAssert flag is a state property on the ServerRMQ and ClientRMQ classes but it's not being used.

Instead, the queueOptions.noAssert is used to determine if the assertQueue should be called or not (can be seen here for server and here for client)

This means that the noAssert flag is not used, at all.

What is the new behavior?

This PR makes sure to use the noAssert property of the class, instead of reading it from the queueOptions

The current workaround (without this PR) is to pass in the noAssert flag in the queueOptions like this:

app.connectMicroservice<MicroserviceOptions>({
  transport: Transport.RMQ,
  options: {
    urls: ['some-url'],
    queue: 'some-queue',
    prefetchCount: 1,
    noAck: false,
    queueOptions: {
      noAssert: false, // current workaround
    },
    noAssert: true // this has no effect currently
  },
});

In order to remain completely backward compatible, I've introduced a fallback on queueOptions.noAssert, so if noAssert is not provided, it falls back to queueOptions.noAssert before using the default value.

Please let me know if you don't agree with this fallback mechanism, I'd be more than happy to change the PR accordingly.

Does this PR introduce a breaking change?

  • Yes
  • No

Other information

@sorooshme sorooshme marked this pull request as ready for review March 2, 2024 22:40
@coveralls
Copy link

Pull Request Test Coverage Report for Build 2e9fdc5c-58b4-40e7-9916-3786ad04d03f

Details

  • 2 of 2 (100.0%) changed or added relevant lines in 2 files are covered.
  • No unchanged relevant lines lost coverage.
  • Overall coverage remained the same at 92.16%

Totals Coverage Status
Change from base Build 2bf2e4c8-5da9-4dd1-8f93-3b733029afc6: 0.0%
Covered Lines: 6736
Relevant Lines: 7309

💛 - Coveralls

@kamilmysliwiec kamilmysliwiec merged commit 07fb4d5 into nestjs:master Mar 17, 2024
3 checks passed
@kamilmysliwiec
Copy link
Member

LGTM

@sorooshme sorooshme deleted the fix-microservice-rmq-noassert-flag branch March 17, 2024 18:30
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants