Prevent @defer & @stream on root mutation or subscription fields

[robrichard]

Context

@benjie: graphql/graphql-spec#742 (comment)

I personally don't think that @defer or @stream should be available within the root selection set of a Mutation or Subscription operation at this time; we should be restrictive to start with and we can lift restrictions later if there's the impetus to do so.

Decision

Discussed in Dec 2021 WG meeting and there was wide agreement on adding validation preventing @defer and @stream on root selection set of Mutation or Subscription operations.

Status

• defined in spec
• implemented in graphql-js

Related

• Mutation interaction with defer & stream

[robrichard]

Discussed in Dec 2021 WG meeting and there was wide agreement on adding validation preventing @defer and @stream on root selection set of Mutation or Subscription operations.

[michaelstaib]

So shall we put this in a validation rule?

[robrichard]

Yes, I will work on adding it to the spec pr and graphql-js.

[robrichard]

I updated the spec and graphql-js PRs adding a validation rule which prevents defer/stream on root mutation/subscription fields

[michaelstaib]

Awesome... I will adopt the spec changes over the weekend.

[CollinCashio]

@michaelstaib @robrichard - I have a use case where I am modifying server data and thus would like to use the mutation operation. During this operation, I am performing a long series of running tasks where I would like to keep the user notified of the progress using @stream that is being made on the server (so I don't have to just show a loading spinner).

I am currently on Hot Chocolate for ASPNet Core version 15.1.4.

Please let me know if you have any questions or even possible suggestions. Thanks!

[benjie]

I personally would have the mutation complete quickly, and then subscribe to updates using a subscription.

Stream and defer are not intended for long-running processes, they're intended to allow a large snapshot of data to be delivered over a slow connection in an order that allows the client to render partial content in the most useful manner whilst the remainder of data is still being downloaded.

[CollinCashio]

Hey @benjie ,

I appreciate the response and I thought about going forward with this approach, but there are some caveats with that approach for what I am trying to accomplish...

A little more background: I am building a developer tool where the GQL operation will run a series of steps to setup infra under a k8s deployment set (start several services, build code, and launch pods).

I would need the mutation to kick off a job and then listen to that job via a subscription - then if I want the job to cancel, I would need to build a separate mutation that cancels the job in my queue (I can break the connection to the subscription via my client app). Also, I would need to ensure that the user subscribing to the event was the one that kicked off the job to begin with to ensure there is no sniffing occurring during transit (not too terribly concerned with this one - just a caveat). This is a good bit of additional complexity for something that is more akin to a Server Sent Event which is similar to the @stream directive implemented in HotChocolate. Is there some other type of SSE with mutations other than subscriptions?

I got the solution working via a query with @stream but if I ever wanted to relay this to outside clients, this may be a bit odd to explain to them as to why it is in a query operation.

[robrichard]

I agree with @benjie that stream and defer are not intended for long-running processes and a subscription is likely a better fit for this.

That being said, the limitation on @defer and @stream for mutations only applies to the root mutation fields. This was due to the spec mandating that multiple root mutation fields are executed serially. Your root mutation field can return an object type and the fields on that object type are not forbidden from using the stream or defer directives.