Fork me on GitHub
#graphql
<
2022-01-10
>
Lennart Buit11:01:20

So today I was debugging a websocket issue. I have the following situation: Two clients, one creates a thing, the other listens for creation of that thing and then sends a subscription document to listen for updates of that same thing. What I notice is that if I do this sufficiently inside the keep alive window, my client will timeout and reconnect. Digging in lacinia-pedestal, this stands out: https://github.com/walmartlabs/lacinia-pedestal/blob/7c65886fc57bb4907a36df9c009e5daefd482fa5/src/com/walmartlabs/lacinia/pedestal/subscriptions.clj#L113, The receiving of data from a client and the keep alive timeout are together in an async/alt!. What I think this means is that a keep alive is sent 25 seconds after the last message was received. So in my case, if I create a subscription at t=0, get an update at t=23 and send my second subscription, I will only get my (first) keep alive at t=58. Is this a bug in lacinia-pedestal? Is it supposed to send a keep alive every 25 seconds even if the client sends messages in between?

Lennart Buit11:01:52

(also funny how a client only starts to consider keep alives if it receives at least one)

hlship18:01:07

I'll take a look at this, hopefully later today.

Lennart Buit20:01:19

we mitigated it partially by halving the keep alive timeout, so we are not in a hurry 🙂. A coworker suggested to split the loop, one that receives messages, one that does the keep alives

hlship21:01:48

Ok, I'll keep this bookmarked until I can take another look at it.

Lennart Buit23:01:47

Sure, no rush! Let me know, either here, on GH, or PM of I can help in any way ^^