Urgent please help ! {status:"error",message:"Internal Server Error"}

[static thorn]

I have created an API gateway and a microservice using a TCP connection as mentioned in the NestJS documentation. I am sending a command and subscribing to it inside a promise, and everything works as expected. The problem arises when I throw an error from the microservice. For example, if I throw a new HttpException while handling a message pattern, the microservice logs the correct error. However, on the gateway side, inside the subscribe object's error field, it shows a generic error like {status: "error", message: "Internal server error"}. I am not using any exception filter on the microservice side. Please help me resolve this issue.

[turbid pollen]

The error gets serialized and loses it's class, and then gets deserialized on the gateway as a regular Error. If you want any specifialized error handling you'll want to extend the ClientProxy class and add your own message deserialization

We have this process outlined in ours dorcs

[static thorn]

This is also not working. I have added the ErrorHandlingProxy class to the client register on the gateway, and it gives the same generic error inside the serializeError function. It does not make sense which error to throw.

I want if my microservice is throwing an error, for example, a BAD REQUEST exception, then it should be received on the gateway side so that my global filter can parse it and provide a valid response on the user side automatically

[turbid pollen]

And you're using this custom proxy instead of the original one, right?

[static thorn]

yes

as mentioned in the docs

[turbid pollen]

Can you show the module and related service?

[static thorn]

actually i dont have auth to share code

is there any sample code from where i can take reference

[turbid pollen]

You can take a look at the tests to see how it's implemented, but I don't have any references otherwise

[static thorn]

could you please share the link of those test

[turbid pollen]

Here's the implementation of the custom proxy in the ClientsModule (ErrorHandlingProxy is higher in the file)
Here's the use of it in a controller
Here's the test that shows it working as intended

[static thorn]

hey the the way i am receiving the error is still the same from microservice

i have took permissions from my seniors and i can add you in the repo

could you plese share you github

i will directly add you

i am sending you images for a better reference

this is my error proxy class

this is where i am using that error proxy class inplace of TCP client

this is where iam calling my microservice

this is where i am throwing the error in the microservice in line 5

[quaint briar]

Suggestion for @static thorn:
Please format your question or answer with Markdown formatting.
It leads to better readability and an easier time to spot problems.
For code blocks, you can wrap your block with three back ticks before and after the block, and after the first three back ticks you can add a language (like ts) to add syntax highlighting.
e.g.

```ts
@Injectable()
export class MySuperAwesomeService {
constructor(@Inject('InjectionToken') private readonly dep: SomeDependency) {}

getRandomNumber(): number {
return Math.round(Math.random() * 1000);
}
}
```

Becomes :point_down:

@Injectable()
export class MySuperAwesomeService {
  constructor(@Inject('InjectionToken') private readonly dep: SomeDependency) {}

  getRandomNumber(): number {
    return Math.round(Math.random() * 1000);
  }
}

:warning: Please do not screenshot code as it causes a number of issues:

• Ease of assistance: if someone wants to copy your code and correct it, they cannot. Making it easy for people to help you is in your best interests.
• Editorializing: it's common to try to make images small, which means you're likely to crop out code relevant to your issue
• Accessibility: wide images can be hard to read on mobile devices, and are impossible for screen readers.
• Legibility: you cannot read screenshots of code directly, instead you have to open them in an enlarged context.
• Bandwidth usage/clutter: some of our members use metered connections, and it is wasteful for them to download images of a text.

For a small amount of code, please use a code-block.

[static thorn]

this is the kind error i am getting in my api gateway

[turbid pollen]

1. are you certain that's where the thrown error is coming from?
2. have you checked that your serialize method is getting the error your expect
3. rather than adding me to your project, I'd suggest you create a minimal reproduction repository that shows your issue without lots of extra setup necessary. No databases, just two simple tcp microservices that can talk to each other

[static thorn]

1. yeah i am 100% sure that is what the an expected error should be 2. no, serialize error on api gateway is getting error in wrong format , 3 okay let me try that

[static thorn]

as far i can understand we need to throw only rpcException from microservice then it works fine

but if i need to throw httpException then what should i do

also if i need do to input validation should i do it in the gateway side or microservice side ?

[turbid pollen]

Ah, I see. You should throw RpcException instances from the microservice server

If you want to throw HttpException instead, you'll need a custom exception filter

[static thorn]

what about this ?

[turbid pollen]

I suggest doing it at the gateway, personally. Do it sooner rather than later, but do it where you find it makes sense

[static thorn]

okay cool thank you for your support

nestjs has best developer support