Message handling infinite loop problem

Hi, I created a new subscription according to the following document, and then after I return new Nack(), I still receive the previous message indefinitely. Is this the problem I set?

dependencies:

• “@nestjs-plus/rabbitmq”: “^1.4.4”,
• “@nestjs/common”: “^6.0.0”,
• “@nestjs/core”: “^6.0.0”,

Message Handling NestJS Plus provides sane defaults for message handling with automatic acking of messages that have been successfully processed by either RPC or PubSub handlers. However, there are situtations where an application may want to Negatively Acknowledge (or Nack) a message. To support this, the library exposes the Nack object which when returned from a handler allows a developer to control the message handling behavior. Simply return a Nack instance to negatively acknowledge the message.

By default, messages that are Nacked will not be requeued. However, if you would like to requeue the message so that another handler has an opportunity to process it use the optional requeue constructor argument set to true.

import { RabbitRPC } from '@golevelup/nestjs-rabbitmq';
import { Injectable } from '@nestjs/common';

@Injectable()
export class MessagingService {
  @RabbitRPC({
    exchange: 'exchange1',
    routingKey: 'rpc-route',
    queue: 'rpc-queue'
  })
  public async rpcHandler(msg: {}) {
    return {
      if (someCondition) {
        return 42;
      } else if (requeueCondition) {
        return new Nack(true);
      } else {
        // Will not be requeued
        return new Nack();
      }
    };
  }
}

my code:

import { RabbitMQModule } from '@nestjs-plus/rabbitmq';
import { Module } from '@nestjs/common';
import { MessagingService } from './messaging.service';
import { MessagingController } from './messaging.controller';
import MSG from './msg.constant';

@Module({
  imports: [
    RabbitMQModule.forRoot({
      exchanges: [
        {
          name: 'emailExchange',
          type: 'topic',
        }
      ],
      uri: 'amqp://root:123456@localhost:5672',
    }),
  ],
  providers: [MessagingService],
  controllers: [MessagingController],
})
export class MessagingModule {}

import { Injectable } from '@nestjs/common';
import { RabbitSubscribe, Nack, RabbitRPC } from '@nestjs-plus/rabbitmq';
@Injectable()
export class MessagingService {
  @RabbitSubscribe( {
      exchange: 'emailExchange',
      routingKey: 'emailRouting',
      queue: 'emailQueue',
  }  )
  public async subscribeHandler(payload: {}) {
    console.log(`Subscribe Received message: ${JSON.stringify(payload)}`);
    return new Nack();
  }
}

[chromey]

Hi @WonderPanda

I just stumbled over this exact problem. Do you still stand by your assessment that using the ClassSerializerInterceptor globally is discouraged? In particular, you mention that global interceptors are applied to all Nest providers, but the Nest docs state that this only true for “every controller and every route handler”, and that’s also my experience - which would mean they in fact only act at network boundaries.

So in light of this, would you reconsider updating the Nack check?

[WonderPanda]

@sjmittal The link you’ve provided is a bit misleading. Interceptors are often used in conjunction with transforming responses to be sent over the network as one of the primary use cases for NestJS is building REST APIs. However, Interceptors make no distinction in behavior based on whether they’re being used at a network boundary or not.

They simply grab the result produced by the method they are “intercepting” and then do something to that payload. There’s no reason to be applying a serialization interceptor globally on all your services. You are actually incurring a performance penalty at the moment because all your messages from Nest Providers need to be processed an additional time. It would be much better for you to configure your serialization interceptor on all of your Controllers so it handles outbound API traffic instead of all internal.

I’m going to close this as it’s not a problem with this library and can be fixed with proper use of Interceptors. However, I have some thoughts about possibly making the Nack check more intelligent so I may add something to the library regardless depending on my availability. If I improve the Nack check in the future I’ll update you in this thread