ValidationPipe in WebsocketGateway returns Internal Server Error
See original GitHub issueBug Report
Note: I created an issue because I experience this issue, but it was already properly described by someone else on StackOverflow, see here.
I’m trying to add some validation to my WebSocketGateway in NestJS. Here’s the code:
// MessageDTO
import { IsNotEmpty, MinLength } from 'class-validator';
export class MessageDTO {
@IsNotEmpty()
username: string;
@IsNotEmpty()
@MinLength(10)
text: string;
}
// Gateway
import { ValidationPipe, UsePipes } from '@nestjs/common';
import { MessageBody, SubscribeMessage, WebSocketGateway, WsResponse } from '@nestjs/websockets';
import { MessageService } from './message/message.service';
import { MessageDTO } from './message/message.dto';
import { Message } from './message/message.entity';
@WebSocketGateway()
export class AppGateway {
constructor(private readonly messageService: MessageService) {}
@UsePipes(new ValidationPipe())
@SubscribeMessage('message')
async handleMessage(@MessageBody() dto: MessageDTO): Promise<WsResponse<Message>> {
const message = await this.messageService.saveMessage(dto);
return { event: 'message', data: message };
}
}
Now, when I try to send a message that doesn’t meet validation rules, it errors out, but the client always receives { status: 'error', message: 'Internal server error'}
. Also, Nest logs the error to the console which should not happen:
Error: Bad Request Exception
at ValidationPipe.exceptionFactory (/usr/src/app/node_modules/@nestjs/common/pipes/validation.pipe.js:78:20)
at ValidationPipe.transform (/usr/src/app/node_modules/@nestjs/common/pipes/validation.pipe.js:50:24)
at processTicksAndRejections (internal/process/task_queues.js:89:5)
at async resolveParamValue (/usr/src/app/node_modules/@nestjs/websockets/context/ws-context-creator.js:104:31)
at async Promise.all (index 0)
at async pipesFn (/usr/src/app/node_modules/@nestjs/websockets/context/ws-context-creator.js:106:13)
at async /usr/src/app/node_modules/@nestjs/websockets/context/ws-context-creator.js:41:17
at async AppGateway.<anonymous> (/usr/src/app/node_modules/@nestjs/websockets/context/ws-proxy.js:11:32)
at async WebSocketsController.pickResult (/usr/src/app/node_modules/@nestjs/websockets/web-sockets-controller.js:85:24)
Current behavior
Throws an error service and client-side, but incorrectly.
Expected behavior
Front-end should have the error returned in the ack
callback.
Environment
Nest version: 7.4.2
Platform: MacOS
Issue Analytics
- State:
- Created 3 years ago
- Comments:6 (4 by maintainers)
Top Results From Across the Web
NestJS - ValidationPipe in WebsocketGateway returns Internal ...
I'm trying to add some validation to my WebSocketGateway in NestJS. Here's the code: // ...
Read more >API with NestJS #4. Error handling and data validation
NestJS shines when it comes to handling errors and validating data. ... error as unintentional and responds with 500 Internal Server Error.
Read more >NestJS Websockets Tutorial #1 - Creating a ... - YouTube
NestJS Websockets Tutorial #1 - Creating a Websocket Gateway Server. Watch later ... An error occurred while retrieving sharing information.
Read more >Globals - @nestjs/common
Defines the controller. Controller can inject dependencies through constructor. Those dependencies have to belong to the same module. Returns ClassDecorator.
Read more >Creating an API with NestJS | SideChannel – Tempest
You can open the src/app.service.ts file and update the return of the ... Internally, @nestjs/config uses the popular library dotenv.
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
But… is this what we want? Is the current logic normal? because it seems odd to me.
The documentation still needs to be updated to mention that this is the error thrown by default. You can change the error type though by making use of the
exceptionFactory
property of theValidationPipe
, or you can follow the advice of my comment above