Note: I'd prefer not to ship this and there's an ongoing discussion in #3345, that requires confirmation before this change is made. This is simply already submitted for reference for the discussion.
The reason why I'd prefer not to ship this is that we're basically forced to simply check using Array.isArray for an array value on the error callback and then circumvent issuing a network error and instead issue a result — potentially merging prior results — when GraphQLError[] is passed as a value.
I find this extremely odd precisely because using next + complete feels much more natural here. GraphQLError[], as part of the ExecutionResult's errors, is a defined shape of a result and can be accepted at any time. Receiving it in errors basically forces a new code path for functionality that already exists.
The addition here basically just uses the next case for error.
Set of changes
Handle unknown[] as GraphQLError[] in error observer callback of subscriptionExchange
Leave note to prevent this being altered or re-used for other transport protocols
Resolves #3345
Summary
Note: I'd prefer not to ship this and there's an ongoing discussion in #3345, that requires confirmation before this change is made. This is simply already submitted for reference for the discussion.
The reason why I'd prefer not to ship this is that we're basically forced to simply check using
Array.isArrayfor an array value on the error callback and then circumvent issuing a network error and instead issue a result — potentially merging prior results — whenGraphQLError[]is passed as a value.I find this extremely odd precisely because using
next+completefeels much more natural here.GraphQLError[], as part of theExecutionResult'serrors, is a defined shape of a result and can be accepted at any time. Receiving it inerrorsbasically forces a new code path for functionality that already exists.The addition here basically just uses the
nextcase forerror.Set of changes
unknown[]asGraphQLError[]inerrorobserver callback ofsubscriptionExchange