Cannot stringify invalid message; isMessage validation for execution result is too strict

A stream payload published by an AsyncIterable returned by execute (from graphql@15.4.0-experimental-stream-defer.1) cannot be stringified

{
  id: '7aef51de-707e-49e5-8cbf-df1bff572e5f',
  type: 'next',
  payload: { data: 'Friend', path: [ 'streamTest', 2 ], hasNext: true }
}

It fails silently with the following message, I had to dig into node_modules and add a bunch of console.logs before I had access to this message.

Error: Cannot stringify invalid message
    at Object.stringifyMessage (/Users/laurin/projects/stream-defer-demo/node_modules/graphql-ws/cjs/message.js:87:15)

It would be nice if such an error would not be swallowed by default but instead forwarded to the console. The user could then overwrite the default behavior.

Aside from that, this message object (returned from execute) should be accepted as a valid message. I don’t understand why exactly the message sent by the server must be validated - as the server constructs it should be fine? Also, the current validation seems to be rather inflexible and must be updated every time graphql supports a new execution result variation. The responsibility for returning a correct result should be within execute.

Reference code:

type Query {
  greetings: [String]
}

query StreamTestQuery {
  streamTest @stream(initialCount: 1)
}

const Query = new GraphQLObjectType({
  name: "Query",
  fields: {
    streamTest: {
      type: GraphQLList(GraphQLString),
      resolve: async function* () {
        for (const item of ["Hi", "My", "Friend"]) {
          yield item;
          await sleep(1000);
        }
      },
    },
})

[enisdenjo]

BTW, the client now fails immediately for some fatal close event codes. This should improve the DX by bringing a problem up sooner.

[enisdenjo]

There, you can now pass whatever you want for the payload. 😄