What's the best way to reject a subscription that has bad arguments?

[reconbot]

I have a subscription that takes arguments. If the arguments are bad I want to communicate that.

• If I throw in my subscribe resolver the connection gets disconnected immediately with the disconnection reason being the error message. If you have any other subscriptions going they get disconnected too.
• If I return immediately, there's no feedback as to why the subscription immediately completes.

I was thinking it might be best to send an error message instead of disconnecting then completing but I don't know what's the easiest to use as a client.

What's the guidance here?

[enisdenjo]

You may gracefully error out a specific subscription in two ways:

• By returning an array of GraphQLErrors in the onSubscribe option
• By supplying your own custom validate function

Whichever way you choose, the returned errors will be transmitted to the client through the Error message and end the subscription keeping the connection alive.

[reconbot]

So this can only be done at the server level? It's not possible to do it at the field level?

[enisdenjo]

Hmm, what do you have in mind? Performing validation during execution in the resolvers, and raise an error from within?

You can always fill in the errors field in the GraphQL ExecutionResult. Beware that since that is technically a result, it would be transmitted through the Next message. It would be the client's responsibility then to check that field in the Sink`s next callback.

[reconbot]

Hmm, what do you have in mind? Performing validation during execution in the resolvers, and raise an error from within?

This is very similar to how non websocket resolvers work. I'm working on a fork of subscriptionless for a product I'm building and while I'm able to test my output against graphql-ws's output this is one area that's a little foggy for me.

I like your idea though. I think I'm going to allow my field level onSubscribe() callback to return an error or an array of errors as a means of validation (followed by the Error message). And leave raising an exception as a runtime error that should close the socket. It seems like a good balance of flexibility and developer ease of use, and we don't conflait server errors with input issues.

[enisdenjo]

This is very similar to how non websocket resolvers work.

graphql-ws is just a transport for GraphQL, resolvers should work exactly the same across whatever transport you throw at it.

I like your idea though. I think I'm going to allow my field level onSubscribe() callback to return an error or an array of errors as a means of validation (followed by the Error message). And leave raising an exception as a runtime error that should close the socket. It seems like a good balance of flexibility and developer ease of use, and we don't conflait server errors with input issues.

You're spot on, these are exactly the decisions made behind the suggested approach in #226 (comment).

• Unhandled (thrown) errors must close the connection because not doing so could be dangerous for the client and the server, following all steps from the security perspective up to performance implications (ex. potential leaks).
• Handled errors that the implementor decides to throw during any callback/hook of graphql-ws should also close the connection giving the user full control.
• Graceful errors, aka. validation errors, are not by any means destructive, they originate from sanity checks and "user is using the app right". They mustn't represent issues with the implementation, but misuse.