Graphql federation & closing subscription on the subgraph

[pdambrauskas]

We are using graphql-ws with Graphql Federation.

It works as follows:

• Client initiates graphql subscription
• Our subscription federation gateway (using useServer/makeServer graphql-ws utility functions in combination with graphql-yoga) delegates subscription to one of the subgraphs by using single Websocket client.
• Subgraph service Gets subscription message and initiates Redis Pub/Sub stream.

It seems that when the client closes the connection, subscription federation gateway does not send CompleteMessage to our subgraph. This means, that our Redis Pub/Sub stream stays active and we eventually get to resource exhaustion.

I had an idea to hook up some logic on onClose callback & send CompleteMessage to ur subgraph from there, but it seems that graphql-ws removes subscriptions form the context:

graphql-ws/src/server.ts

Line 860 in 102e634

ctx.subscriptions = {}; // deleting the subscription means no further activity should take place

Are there any other ways/suggestions how to address this issue?
@enisdenjo

[enisdenjo]

Not only are the subscriptions removed from the context, the clients are disconnected immediately after:

graphql-ws/src/server.ts

Lines 862 to 867 in 102e634

	// we return all iterable subscriptions immediatelly, independant of the order
	await Promise.all(
	Object.values(subs)
	.filter(isAsyncGenerator)
	.map((sub) => sub.return(undefined)),
	);

Meaning, even if we left the subscriptions intact, the clients' connections will be closed right after.

---

I'd instead focus on fixing this:

It seems that when the client closes the connection, subscription federation gateway does not send CompleteMessage to our subgraph.

The CompleteMessage is sent as soon as the the subscription completes, i.e. as soon as the subscription iterable returns. Meaning, your iterable is not returning/completing and hence not emitting a CompleteMessage.

[pdambrauskas]

I think I didn't explain my problem clearly enough. This is specific to graphql Federation:

• By default client itself sends completion messages which get forwarded to subgraph when client unsubscribes gracefully.
• If client just disconnects - no completion messages are generated, meaning subgraph does not get notified. (subscription iterable still gets returned).

Specifically I'm using this approach:
https://the-guild.dev/graphql/stitching/docs/getting-started/remote-subschemas#combining-ws-and-http-executors-to-use-ws-only-for-subscriptions

Without changing the library itself I've managed to hack some solution that addresses the problem:

function buildCombinedExecutor() {
  const httpExecutor = buildHTTPExecutor({
    // ... not important ...
  })
  
  // 1. Capture client socket
  let socket: WebSocket
  const wsExecutor = buildGraphQLWSExecutor({
    // ...
    // 2. Use custom ID, on downstream service
    generateID: (payload) => payload.extensions.subscriptionId
    on: {
      connected: (ws) => socket = ws,
    }
  })
  return executorRequest => {
    if (executorRequest.operationType === 'subscription') {
      executorRequest.extensions ||= {}
      executorRequest.extensions.subscriptionId = uuidv4()
      const result = wsExecutor(executorRequest)
      return {
        ...result,
        return: async (args) => {
          // 3. Send completion with every iterable return
          await socket.send(buildCompletionMessage(executorRequest.extensions.subscriptionId))
          return result.return(args)
        },
      }
    }
    return httpExecutor(executorRequest)
  }
}

While it works, it has some these disadvantages:

• it results in multiple completion messages, when the client completes subscription in a graceful way
• it requires mutating executorRequest
• capturing client socket on connected callback looks a bit hack.