…bscriptionEvent

as it is used during ExecuteRootSelectionSet

and some baseline collection language for comparison

extracted from graphql#742

Authored-by: Rob Richard <[email protected]>

Authored-by: Rob Richard <[email protected]>
Co-authored-by: Benjie Gillam <[email protected]>
Co-authored-by: Yaacov Rydzinski <[email protected]>

Authored-by: Rob Richard <[email protected]>
Co-authored-by: Benjie Gillam <[email protected]>
Co-authored-by: Yaacov Rydzinski <[email protected]>

This is a simplified version of GetIncrementalResult useful for the initial result.

Readers approaching the spec in order may benefit from a bit of repetition.

pendingInfo => deferState

as we now track ids separately from the defer state; the prior language was left over from an earlier branch

to explain why and how it manages defer ordering

when releasing pending futures, they can simply be appended to remainingFutures, i.e. the uncompleted futures, for future processing after the pending is issued.

we should use newFutures to add a bit more specificity

within the section for making sure we don't send incremental entries twice

1. we need to iterate through the incremental entries that are being sent, not the completed entries

2. we need to update the new pending incremental entries correctly.

leaving just futures

previously, we mutated a list (along with some other bugs)

…payload stream

The update stream suppresses future completion that should not lead to a response, i.e. now all incremental entries for a given fragment have been completed.

The payload stream does the response formatting.

NOTE: I think it is possible that we can move payload response formatting out of the execution section entirely, and into the Response section.

…xactly once

we start at the number of deferred fragments and then go down

have to update the pendingFutures set when completing a fragment