SpacetimeDB does not respond to Websocket Ping if it is still responding to another message

[ResuBaka]

From what I found out and would even had guess a websocket server should still response to pings and send a pong back.

But when I used a client with a relative small default timeout of 30sec and spacetimedb did not response in that time frame to ping with a pong because it was still responding really slow or better said a bug in tungstenite-rs on client side to be really slow on big responses. (Which is now fixed in version 0.27.0 if you guys want to update your version).

I am not sure if that is fixed in the meantime (last 2 months). But it would be nice if you guys could fix it so you still response to control frame when you are responding to a client. As this could also maybe be a problem in real world usage if people have slow connections, instead of my problem where I had a client which wanted to download on subscribe ~1GB of data and on top of that had a bug in the websocket client.

[bfops]

Thank you for reporting! We'll look into improving the experience here.

[ResuBaka]

I have now taken a quick look. I thing the issue is here https://github.com/clockworklabs/SpacetimeDB/blob/master/crates/client-api/src/routes/subscribe.rs#L280 as that blocks the tokio::select! if it takes a long time to send the message to the client for what ever reason it takes a long time. But I could be wrong if that blocks that long as it awaits sending the whole message to the client.

Maybe the info help you. Is there a reason why you have not extra loop/thread which works on sending to the client and instead do both in the same tokio thread?

[ResuBaka]

I think this Pull Request will fix the issue: #2906

[bfops]

That PR is now released as part of v1.3.0! Let us know if you still have the same behavior.