✅ Deploy Preview for compassionate-pike-271cb3 ready!

Name	Link
🔨 Latest commit	4ff4d05
🔍 Latest deploy log	https://app.netlify.com/sites/compassionate-pike-271cb3/deploys/64e771075ad340000855aa59
😎 Deploy Preview	https://deploy-preview-3886--compassionate-pike-271cb3.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify site configuration.

Hi @yaacovCR, I'm @github-actions bot happy to help you with this PR 👋

This week's update:

I have pushed a few fixes to the spec and impl PRs ==> these revolve mostly around when it's actually appropriate to figure whether a deferred fragment is "empty," we now do so lazily rather than eagerly to avoid some edge cases.

This serendipitously also simplifies the Executor==> Publisher event/messaging model; previously we had a funny hook/event/message from the Executor that was triggered/sent for every grouped field set executed on an object field. If named appropriately, its weirdness would really have stood out, something like: Hit_Checkpoint_Where_We_Have_Initialized_Defers_at_a_Given_Field_Level

Now the only events/messages from the Executor to the Publisher center around what has conclusively happened to a given IncrementalDataRecord:

(A). DeferredGroupedFieldSet_Has_Completed
(B). DeferredGroupedFieldSet_Has_Errored
(C). StreamItemsRecord_Has_Completed
(D). StreamItemsRecord_Has_Completed_As_Closing_Iterator_Without_Data
(E). StreamItemsRecord_Has_Errored

or what has happened at a given path of execution, i.e.:

(F). Path_Has_Errored_Either_In_Initial_Result_Or_Within_IncrementalDataRecord

No hidden knowledge required.

For those interested:

The birds eye flow within the implementation/spec:

1. The Executor spins up a Publisher and initiates execution of the initial result.
2. As directed by any @defer and @stream directives it encounters, the executor requests the publisher to generate IncrementalDataRecords and semi-concurrently initiates execution of the associated grouped field sets for deferred fragments and completion of the given items for streams.
3. The Executor reports the 6 events (A)-(F) to the Publisher [which may or may not lead to filtering of those IncrementalDataRecords from the final stream].
4. When the initial result completes, the Executor notifies the Publisher.
5. The Executor then checks with the Publisher whether any subsequent results are pending, and, if so, returns a subscription to the stream from the Publisher. Otherwise, it just returns the initial result.

The Publisher tracks all the state necessary to make sure that the above works, including whether results are ordered correctly, filtered when appropriate, etc, etc.

In fact, because the Executor doesn't itself mutate anything about the IncrementalDataRecords it receives, it doesn't even actually need to receive the IncrementalDataRecord at all in step (2) above. It could simpy receive an id that the Publisher knows points to such a record, so that events (A)-(F) can reference that id in further communications to the Publisher.

Merging to implement graphql/defer-stream-wg#69