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
There are 2-6 cases in which we might want to call .return() on an asyncIterator being used to iterate through a list.
If a non-nullable list item errors, and we abort iteration.
without the use of the @stream directive or with erroring indices prior to hitting initialCount
without the use of the @stream directive or with erroring indices prior to hitting initialCount, even when the entire list is not included in the response anyway because of null bubbling from somewhere else...
with the use the @stream directive with errors within streamed items, i.e. for nonreconcilable stream items.
when streams are "filtered" i.e. when early execution results in asyncIterators that are encountered but not actually send to the client.
When using incremental delivery, when .return() is called on the subsequentResults iterator explicitly, we should forward that to the underlying stream asyncIterator.
for streams that would have been sent to the client
for streams that would have been "filtered"
In each of these scenarios, we would have to think about how to forward errors from .return() to the client if we would like to do so. Right now, the current state is that we are not tackling how to return errors from .return() at all with respect to (1), and that's probably how it should stay until users of graphql-js can weight in on what this API should look like.
See: #4142 for an attempt to address (only some!) of the above cases.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
There are 2-6 cases in which we might want to call
.return()
on anasyncIterator
being used to iterate through a list.@stream
directive or with erroring indices prior to hittinginitialCount
@stream
directive or with erroring indices prior to hittinginitialCount
, even when the entire list is not included in the response anyway because of null bubbling from somewhere else...@stream
directive with errors within streamed items, i.e. for nonreconcilable stream items.asyncIterators
that are encountered but not actually send to the client..return()
is called on thesubsequentResults
iterator explicitly, we should forward that to the underlying streamasyncIterator
.In each of these scenarios, we would have to think about how to forward errors from
.return()
to the client if we would like to do so. Right now, the current state is that we are not tackling how to return errors from.return()
at all with respect to (1), and that's probably how it should stay until users ofgraphql-js
can weight in on what this API should look like.See: #4142 for an attempt to address (only some!) of the above cases.
Beta Was this translation helpful? Give feedback.
All reactions