Errors in Subscription operations aren't propagated by the graphql-ws client as expected

[shtaif]

Actual Behaviour

Calling a subscription whose backend resolver errors out unfolds into this:

import { WebSocket } from 'ws';
import { createClient as createGqlWsClient } from 'graphql-ws';

const gqlWsClient = createGqlWsClient({
  url: `ws://localhost:4000`,
  webSocketImpl: WebSocket,
});

const subscriptionIter = gqlWsClient.iterate({
  query: `
    subscription {
      myErroringSubscription
    }`,
});

try {
  await subscriptionIter.next();
} catch (err) {
  err; // an instance of `CloseEvent`
  err.code; // 4500
  err.type; // 'close'
  err.reason; // 'Oh bummer...'
  // and some other technical properties...
}

/*
  1. The erroring field resulted the subscription iterable throwing out altogether
  2. What's thrown is a `CloseEvent` with some technical data, which only carries the error text message thrown from the resolver - no access to any other standard GraphQL error properties and `extensions` in particular.
*/

On the other hand, calling a query whose backend resolver errors out ends up in:

import { WebSocket } from 'ws';
import { createClient as createGqlWsClient } from 'graphql-ws';

const gqlWsClient = createGqlWsClient({
  url: `ws://localhost:4000`,
  webSocketImpl: WebSocket,
});

const queryIter = gqlWsClient.iterate({
  query: `
    query {
      myErroringQuery
    }`,
});

const next = await queryIter.next();

next.value;
/* {
  "data": null,
  "errors": [
    {
      "message": "Oh bummer...",
      "locations": [
        {
          "line": 3,
          "column": 7
        }
      ],
      "path": [
        "myErroringQuery"
      ],
      "extensions": {
        "foo": "bar"
      }
    }
  ]
} */

/*
 1. The result iterable did not throw an error and just yielded a value.
 2. The yielded value shows what looks like the original response you'd expect, including all the standard error properties and the backend-customized `extensions` in particular.
*/

Expected Behaviour

I expected that graphql-ws's client, as it encounters a Subscription error - would yield one last message that looks just like the one yielded when the client encounters a Query error (as illustrated above), and the iterable would then complete.

Further Information

The exact GraphQL API setup code that produces all which was described

Sample setup for a GraphQL API which holds an erroring query operation and an equivalent erroring subscription:

import { WebSocket, WebSocketServer } from 'ws';
import { useServer } from 'graphql-ws/lib/use/ws';
import { makeExecutableSchema } from '@graphql-tools/schema';
import { GraphQLError } from 'graphql';

const schema = makeExecutableSchema({
  typeDefs: `
    type Query {
      myErroringQuery: String!
    }

    type Subscription {
      myErroringSubscription: String!
    }
  `,

  resolvers: {
    Query: {
      myErroringQuery: async () => {
        throw new GraphQLError('Oh bummer...', { extensions: { foo: 'bar' } });
      },
    },
    Subscription: {
      myErroringSubscription: {
        subscribe: async function* () {
          throw new GraphQLError('Oh bummer...', { extensions: { foo: 'bar' } });
        },
      },
    },
  },
});

useServer({ schema }, new WebSocketServer({ port: 4000 }));

The goal is to have errors returned from the GraphQL backend convey extra information and context populated in the extensions property as part of the standard resolved fields' error structures (as can be passed to graphql's GraphQLError class constructor).

However, it appeared for me that there's currently a difference in how erroring is treated and propagated when it is resulting from calling a Query operation vs calling a Subscription operation.

Debug info

In case it helps to pin down on the source of the problem - it appears that if we'd take the same subscription resolver from the setup code above and just change the subscribe function to either directly throw, or otherwise return a rejected promise - instead of returning an async iterable that throws, we'd then get the same desired behavior that occurs in the erroring query case.
e.g:

  resolvers: {
    Query: {
      myErroringQuery: async () => {
        throw new GraphQLError('Oh bummer...', { extensions: { foo: 'bar' } });
      },
    },
    Subscription: {
      myErroringSubscription: {
-        subscribe: async function* () {
+        subscribe: async () => {
          throw new GraphQLError('Oh bummer...', { extensions: { foo: 'bar' } });
        },
      },
    },
  },

Thanks for any help!!! 💛

[enisdenjo]

On the other hand, calling a query whose backend resolver errors out ends up in [...]

That is because the resolvers in graphql-js schema catch errors and return them in the execution result. While, on the other hand, throwing from subscribe in a GraphQL schema will not catch and will bubble the error instead.

If an error is thrown from anywhere on a graphql-ws powered backend - it results in the server closing the connection. It does not matter if the client is subscribing or querying.

See this discussion and how to remidy the subscribe function.

[shtaif]

Thanks @enisdenjo!
I understand now that graphql-ws's WebSocket server is aimed to be a mere WS transport for the standard graphql-js engine, carrying over its original semantics and behavior, nonetheless if some of them might seem questionable in some context.

See this discussion and how to remidy the subscribe function.

-> I adapted the patching for the subscribe function through useServer's options similar to the suggested on referenced docs and it's looking good to me for now on my side 😃✌🏻