There is a new kind of standard, different from what lacinia used to be. And there is also another one. Subscriptions still are a bit messy, and not al servers and clients are compatible. https://wundergraph.com/blog/quirks_of_graphql_subscriptions_sse_websockets_hasura_apollo_federation_supergraph might help.

I can throw it against our test suite tomorrow, @U04VDKC4G, if that helps

We have some subscriptions tests

Using the ‘old’ protocol

Test suite doesn't say much IMHO. It should work with 'most' clients. Soms libraries like graphql-kotlin have https://github.com/ExpediaGroup/graphql-kotlin/tree/master/servers/graphql-kotlin-spring-server/src/main/kotlin/com/expediagroup/graphql/server/spring/subscriptions subscription protocols included. I fear ideally, lacinia should do something similar.

Well I’m just responding to the feeling of it being broken. I have a set of tests pretending to be a ‘subscription-transport-ws’ client, it is little to no effort for me to try that with a newer l-p version — maybe it runs perfectly and we have nothing, maybe it helps narrowing down what is happening.

I’ve got quite far using subscriptions, they work fine with the Altair GUI, I’m currently wrangling using the re-graph client, including a wrapper to wait on responses from the subscription itself

The issue in the demo is that it produces an event (invokes the source stream function) but the result ends up being nil. So the WS part seems to be working fine, but something is amiss in the demo or in the lacinia-pedestal code when it comes to evaluating a value passed to the source stream and then sent over the WS back to the client.

Explanation: I have a tiny demo in lacinia-pedestal that I use for manual sanity checking and it's not working even though it should.

I'm kind of at the "how did this ever work" stage of diagnosis.