How can I preserve original error details in NestJS microservices with RabbitMQ?

When using NestJS microservices and RabbitMQ, error objects are serialized (typically via JSON) before being sent over the transporter. As a result, non-enumerable properties (like the ones on many built‑in exceptions) won’t be preserved. In your example, when you throw an UnprocessableEntityException, its properties (like the message) are lost during serialization—resulting in an empty object when you attempt to handle it on the client side.

Below are a few techniques to handle errors appropriately:

---

1. Use RpcException

Instead of throwing a standard HTTP exception (e.g., UnprocessableEntityException), throw an RpcException from the @nestjs/microservices package. This class is designed for RPC patterns and its payload is included explicitly in the error response.

TYPESCRIPTCopied
import { RpcException } from '@nestjs/microservices';

public async findByEmail({ email }: { email: string }): Promise<UserEntity> {
  const repository = this.getRepository(UserEntity);

  const user = await repository.findOneBy({ email: email });
  if (user) {
    throw new RpcException({
      error: 'User exists',
      message: 'Email already exists.',
    });
  }

  return user;
}

On the caller side (auth service), the observable’s error callback will receive the serialized error payload.

---

2. Convert Exceptions to Plain Objects

If you need to throw HTTP exceptions for other reasons, you can convert them into a plain object that preserves the required properties. For example, you might do something like this before throwing:

TYPESCRIPTCopied
public async findByEmail({ email }: { email: string }): Promise<UserEntity> {
  const repository = this.getRepository(UserEntity);

  try {
    const user = await repository.findOneBy({ email: email });
    if (user) {
      const errorPayload = {
        statusCode: 422,
        message: 'Email already exists.',
        error: 'Unprocessable Entity',
      };
      throw new RpcException(errorPayload);
    }

    return user;
  } catch (e) {
    throw e;
  }
}

This way, the error payload becomes a plain object that is easily serialized and transferred.

---

3. Consider Exception Filters

While RpcException is generally better for microservices, you could also use custom exception filters on the server side to transform exceptions into plain objects that the microservice transporter can serialize.

For example, define a filter:

TYPESCRIPTCopied
import { Catch, RpcExceptionFilter, ArgumentsHost } from '@nestjs/microservices';
import { Observable, throwError } from 'rxjs';

@Catch()
export class AllExceptionsFilter implements RpcExceptionFilter {
  catch(exception: any, host: ArgumentsHost): Observable<any> {
    const errorResponse = {
      statusCode: exception.status || 500,
      message: exception.message || 'Internal server error',
    };
    return throwError(() => errorResponse);
  }
}

Then apply it as a global filter for your microservice. This captures any exception, converts it to a plain object, and passes it along to the client.

---

4. Observable and Promise Considerations

Wrapping your observable in a Promise isn’t inherently a hack—it’s a common pattern when you need to bridge between RxJS observables and async/await syntax. If you prefer to work with observables and RxJS operators throughout your microservice, you could refactor to avoid wrapping manually:

TYPESCRIPTCopied
public register({ dto }: { dto: UserRequestDto }): Observable<UserResponseDto> {
  return 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 or return the existing user
      return throwError(() => new RpcException({ message: 'User already exists' }));
    }),
  );
}

This approach lets you work fully in the RxJS paradigm.

---

Summary

• Error Serialization: The original error is lost because properties of exceptions aren’t automatically serializable.
• RpcException: Use RpcException to explicitly pass your error payload.
• Plain Objects: Convert exceptions to plain objects that can be reliably transferred.
• Exception Filters: Use filters to control the shape of the error response.
• Observables vs. Promise: Converting to promises is acceptable when necessary, but consider consistent usage of either observables or async/await.

Using these patterns will ensure that you retain meaningful error information throughout your microservices communication.