How can I capture the detailed original error in a NestJS microservices RabbitMQ setup?

Below is an explanation of what’s happening and some patterns you can use to propagate richer error data between microservices in NestJS.

Why the Error Details Are Lost

When you throw an exception such as an UnprocessableEntityException in your repository, Nest’s microservices transport layer (RabbitMQ in your case) serializes the error into a plain object. By default, only minimal error information is sent (often just a status code and message) and the original error reference or stack isn’t retained. As a result, when the error lands on the client side (your auth service), you only see an empty object or generic error – the original details are lost.

Nest’s microservices layer uses built‐in error serialization and sometimes “sanitizes” the error contents for transport. Therefore, throwing an Error instance directly (or a subclass thereof) might not behave as you expect.

Recommended Patterns

1. Use RpcException Instead of Direct Throwing:
   Instead of throwing standard HTTP exceptions (like UnprocessableEntityException) directly in your microservice handler, wrap your error message in Nest’s RpcException. This is designed for RPC-based communication and ensures that your error data is serialized in a controlled manner.

   TYPESCRIPTCopied
   import { RpcException } from '@nestjs/microservices';
   import { UnprocessableEntityException } from '@nestjs/common';
   
   public async findByEmail({ email }: { email: string }): Promise<UserEntity> {
     const repository = this.getRepository(UserEntity);
   
     try {
       const user = await repository.findOneBy({ email });
       if (user) {
         // Wrap the error in an RpcException to allow proper serialization.
         throw new RpcException(
           new UnprocessableEntityException('Email already exists.'),
         );
       }
       return user;
     } catch (e) {
       throw e;
     }
   }

2. Custom Error Envelopes:
   You can choose to wrap your error data in a custom error envelope (for example, an object containing message, errorCode, etc.) and throw that. Then, on the client side, check for this structure to determine further action.

   TYPESCRIPTCopied
   // In your repository or service
   if (user) {
     throw new RpcException({
       statusCode: 422,
       message: 'Email already exists.',
       error: 'UnprocessableEntity'
     });
   }

3. Using RxJS Operators Instead of Wrapping in a Promise:
   Instead of wrapping your client call in a new Promise, consider using RxJS utilities (like firstValueFrom) to convert the observable to a promise. This makes your code more idiomatic for NestJS microservices.

   TYPESCRIPTCopied
   import { firstValueFrom } from 'rxjs';
   
   public async register({ dto }: { dto: UserRequestDto }): Promise<UserResponseDto> {
     try {
       const userResult = await firstValueFrom(
         this.usersController.send(FIND_USER_BY_EMAIL, dto.email)
           .pipe(
             switchMap((res) => {
               if (res === null) {
                 return this.usersController.send(CREATE_USER, dto);
               }
               // Optionally, throw an error if the user exists
               throw new Error('User already exists');
             })
           )
       );
       return userResult;
     } catch (e) {
       // Now e should contain more of your custom error data.
       throw e;
     }
   }

4. Exception Filters:
   If you have similar error-handling requirements across your microservices, consider creating a custom exception filter on the microservice side. This filter can intercept exceptions thrown from your handlers, format them, and then send them over the wire with all the relevant details.

Conclusion

The key issue is that when errors are transmitted via the microservices layer, they are subject to serialization rules that strip away properties. By explicitly wrapping errors in an RpcException (or by creating custom error envelopes), you gain control over how much detail is sent. Additionally, converting observables with operators like firstValueFrom reduces some promise-related “hacks” and lets your code remain more idiomatic to NestJS.

Following these patterns should help you preserve your error details and streamline error-handling across your distributed services.