Skip to content
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

Closed
dantman opened this issue May 14, 2019 · 4 comments
Closed

Exception filters do not catch errors for subscriptions #249

dantman opened this issue May 14, 2019 · 4 comments

Comments

@dantman
Copy link
Contributor

dantman commented May 14, 2019

I'm submitting a...


[ ] Regression 
[x] Bug report
[ ] Feature request
[ ] Documentation issue or request
[ ] Support request => Please do not submit support request here, instead post your question on Stack Overflow.

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

  • Setup NestJS with GraphQL
  • Setup subscriptions according to the manual
  • Add a subscription to a resolver that throws an error
  • Implement a exception filter and add a @UseFilters for it to the resolver class
  • Test it out / debug it, the exception filter will not be called

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


Nest version: 6.2.0, @nestjs/[email protected]
 
For Tooling issues:
- Node version: v12.1.0
- Platform: Mac
@kamilmysliwiec
Copy link
Member

Please, provide a minimal repository which reproduces your issue, it would help us a lot!

@dantman
Copy link
Contributor Author

dantman commented May 15, 2019

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 (modified) has been added by the exception filter and the error has been logged to the console by the exception filter.

{
  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
  }
}

@kamilmysliwiec
Copy link
Member

Thanks for the repo! @nestjs/graphql package is using the generic implementation of ExternalContextCreator which allows us to wrap Gql resolvers with enhancers (guards, interceptors, etc.). The default context creator of Nest isn't compatible with JavaScript generators (because they actually don't make sense in 99% of Nest use-cases), and thus, we don't call yourGeneratorName.next() in the composed context functions. If you change your existing implementation to the following one:

@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.

@lock
Copy link

lock bot commented Apr 25, 2020

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.

@lock lock bot locked as resolved and limited conversation to collaborators Apr 25, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

2 participants