Async-graphql: Internal context missing when there's no `connection_init` frame

[leebenson]

After working on https://github.com/timberio/vector/pull/6871, I discovered an error in our Vector API client where a start operation was sent before a connection_init message.

A side-effect to this is that context provided in graphql_subscription_with_data() isn't added, because there's no initial payload to merge with. This resulted in panics when using Context.data_unchecked.

It would be useful for 'internal' context to be injected without relying on a _connection_init_ message from the client so this doesn't need to be a checked operation.

If it _is_ provided, then this would be merged with the initial payload as normal.

Does that seem reasonable? Or would you recommend simply using checked operations at all times?

[sunli829]

I checked the protocol specification of graphql-ws, connection_init message must be sent first by the client during the handshake phase, so when the handshake phase is not completed, the client start a subscription should get an error.

What do you think?

[leebenson]

Agreed. If connection_init is missing, I think we should probably avoid starting the subscription, rather than allowing it to be an in 'incomplete' state 👍🏻

[sunli829]

Now, if the client sends start before connection_init, the connection will be immediately disconnected and return 1011 error.

Released in v2.6.5

[leebenson]

Awesome, thanks @sunli829 ! 🚀