Do subscriptions catch errors?

[ricardo-valero]

I'm having trouble with some of my async iterators in my subscriptions, are errors propagated in the subscribe method?
when using subscriptionField

[hayes]

Can you elaborate a little more on this question, or provide an example?

In pothos, a subscription field has 2 callbacks: the subscribe function, and the resolve function, both of these are passed directly to the underlying field in the generated graphql schema, so the details of how errors are handled are not controlled by pothos, but are actually handled by the graphql execution engine you are using.

subscriptions can error in multiple ways, the initial function can throw an error, but it also should return an async iterator, where it can emit an error or rejected promise when the iterator is consumed. In each of these cases though, I would expect the error to be "handled", but the way the error is handled (eg closing the connection, sending a payload with an error response, etc) depends on the specifics of how the server is set up, and when/where/how the error is thrown

[ricardo-valero]

Oh thank you, I am having issues with both graphql-ez and graphql-yoga which both use graphql-helix (I think).

My use case is opening a tcp connection using Node's net

1. receive a single response for which I created a mutation and
2. subscribe to an event emitter for which I created a subscription.

My mutation handles the errors just fine and since my implementation for both was basically the same, I thought the errors were not correctly thrown.
But now I see it probably is the engine's fault.