-
Notifications
You must be signed in to change notification settings - Fork 396
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Exception filters do not catch errors for subscriptions #249
Comments
Please, provide a minimal repository which reproduces your issue, it would help us a lot! |
Here's a test repository: https://github.com/dantman/nestjs-graphql-subscription-exception-filter-test Test it out in the playground: http://localhost:3000/graphql This will successfully fetch a test Acme object: {
acme(id: 1) {
id
title
}
} This will throw an Acme error, you'll notice that {
acme(id: 2) {
id
title
}
} This will open a subscription that will successfully return one test Acme object and close: subscription Acme {
watchAcme(id: 1) {
id
title
}
} This will open a subscription that will throw an Acme error, you'll notice that the error is unmodified and the error has not been logged to the console by the exception filter subscription Acme {
watchAcme(id: 2) {
id
title
}
} |
Thanks for the repo! @Subscription(returns => Acme, { resolve: (acme: any): any => acme })
watchAcme(@Args('id') id: number): AsyncIterable<Acme> {
if (id !== 1) {
throw new AcmeError(`No acme #${id}`);
}
return this.watchAcmeGenerator(id);
}
async *watchAcmeGenerator(@Args('id') id: number): AsyncIterable<Acme> {
yield new Acme(id, 'Test');
} Nest will properly catch your exception through an exception filter. |
This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
I'm submitting a...
Expected behavior
Exception filters should catch errors in subscriptions and allow filtering.
Current behavior
Exception filters catch errors thrown in http resolvers/mutations and the error Apollo reports can be replaced. But for subscriptions the
catch
of an exception filter is not called and the thrown error goes directly to Apollo and cannot be replaced.Minimal reproduction of the problem with instructions
What is the motivation / use case for changing the behavior?
GraphQL and HTTP API calls use completely different error types. I'd like to throw custom general errors from my services e.g. AuthorizationTokenFailure, EntityDoesNotExist, etc... and convert them to a Http error or an Apollo error depending on the context. However this does not work if exception filters work in resolvers/mutations but not GraphQL subscriptions.
Environment
The text was updated successfully, but these errors were encountered: