You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 text was updated successfully, but these errors were encountered:
The review of error handling under #1067 uncovered an inconsistency in error handling. If the exception coming from the
Publisher
side 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
SubscriptionPublisherException
as a result of an annotated exception handler or aSubscriptionExceptionResolver
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 text was updated successfully, but these errors were encountered: