The review of error handling under #1067 uncovered an inconsistency in error handling. If the exception coming from the Publisherside is a SubscriptionPublisherException, it is written as a GraphQL spec map with an "error" section, followed by a "complete" message. This help the client understand the stream was ended intentionally and to provide a reason. For any other error, however, we simply close the SSE stream without writing anything.
In most cases we do expect SubscriptionPublisherException as a result of an annotated exception handler or a SubscriptionExceptionResolver have resolved it to GraphQL errors. However, in the unlikely event that it wasn't resolved at all, we still need to create a default GraphQL error, and write that before sending "complete".
The review of error handling under #1067 uncovered an inconsistency in error handling. If the exception coming from the
Publisherside is aSubscriptionPublisherException, it is written as a GraphQL spec map with an "error" section, followed by a "complete" message. This help the client understand the stream was ended intentionally and to provide a reason. For any other error, however, we simply close the SSE stream without writing anything.In most cases we do expect
SubscriptionPublisherExceptionas a result of an annotated exception handler or aSubscriptionExceptionResolverhave resolved it to GraphQL errors. However, in the unlikely event that it wasn't resolved at all, we still need to create a default GraphQL error, and write that before sending "complete".