search

apollographql / subscriptions-transport-ws

:arrows_clockwise: A WebSocket client + server for GraphQL subscriptions
https://www.npmjs.com/package/subscriptions-transport-ws
MIT License
1.52k stars 342 forks source link

Subscription do not trigger hooks set in Apollo server plugins #781

Closed Sytten closed 2 years ago

Sytten commented 4 years ago

Reposting my original issue here since it is more relevant to this repo.

When using subscriptions, the server does not currently trigger the hooks of the installed plugins for an Apollo server. This means that if I user decided to handle errors in didEncounterErrors for example, it will completely bypass it and the user might never be alerted of errors in production (It does however call formatError).

michaelsharpe commented 4 years ago

I am experiencing this as well. Our entire application communicates via websockets using this transport, and I would like to be able to give detailed error reporting to our sentry integration via a plugin. However, I can not currently as none of our requests trigger off the proper hooks. If I knew where to start, I would take a crack at fixing this myself. Thanks!

Sytten commented 4 years ago

Since the subs module is "independent" from the apollo server, it has no notion of the hooks and the lifecycle. It only has the interface for the formatError (https://github.com/apollographql/subscriptions-transport-ws/blob/master/src/server.ts#L30). Like I said many times, this feels like abandoned software which I don't understand since Subscriptions are quite a big part of GraphQL. But looking at the roadmap for apolo server v3, it says Removal of subscription-transport-ws in favor of a built-in solution that takes full advantage of the main request pipeline. So I don't think we will have much progress here.

michaelsharpe commented 4 years ago

@Sytten Thanks for finding that! Just going to have to wait till the officially integrated websocket transport into the apollo server I guess. I was really hoping to get more detailed errors logging properly. Thanks!

Sytten commented 4 years ago

@michaelsharpe No worries, what I did in the meantime is wrap the resolve part of the subscriptions in an error handler that catches the errors and report them. Not ideal but it works.

RichardWright commented 3 years ago

@Sytten Hi, nice to hear someone being quite clear about this issue. I'm looking at instrumenting subscriptions, do you have any recommendations for wrapping them?

Sytten commented 3 years ago

Not really since we use the nexus schema library I just created a new subscriptionField method that wraps the resolve method in a try-catch and report errors.