Unify behavior of Websocket validation and Http Validation

[MickL]

Is there an existing issue that is already proposing this?

• I have searched the existing issues

Is your feature request related to a problem? Please describe it

1. For http controller we can set up a global validation pipe, we cant do this for gateways (every gateway needs to have a @UsePipes decorator)
2. A failed validation within a gateway throws and logs an error: ERROR [WsExceptionsHandler] error-text while in HTTP controller it silently returns it as an error response
3. Errors are "returned" within a new event exception which means errors arrive to the client without any relationship while for HTTP request the error is returned as a response. If sending 3 websocket events to the server and getting back one exception event it is not possible to know which of the 3 sent events caused the exception. But even if sending only one event it is hard to know that it failed: Set a timeout and check if no response but an exception event came in within this timeframe?
4. This one might be optional/opinionated: A gateway currently is registered as a service while for me it has mostly the same purpose as a http controller does

Describe the solution you'd like

Basically I would love to have the behavior of Websockets to be the same as for HTTP controllers:

1. Either app.useGlobalPipes() should apply also to Gateways OR add a new function to add global pipes to Gateways
2. Don't throw an error, instead silently return the error object
3. This could be set by a configurable option: When the client sends something to the Nest app and an error occurs the error should be sent as the response to the request. Even tho socket.io doesnt have error response's we could define a configurable interface that will act as an error response, e.g. { error: true; errorType: WsErrorType; data: any; }
4. This one might be optional/opinionated: Gateways should be registered as a controller instead of a service

What is the motivation / use case for changing the behavior?

All of this could probably be archived by adding custom exception filter but I thought that the purpose of a framework like NestJS is to abstract this implementation details so the programmer can just focus on his application.

P.S. I think it would be great to leave closed issues open for discussion. Sometimes I find old issues that I would like to comment (e.g. adding a solution or additional information to the described issue) but all issue that are closed are also locked and cant be commented.

[Maligosus]

Hello, once upon a time I created issue #11461. I also created PR. IF it will be approved, you can use this PR #11462