streamlit does not produce WebSocket ping frames

[toredash]

Checklist

• I have searched the existing issues for similar issues.
• I added a very descriptive title to this issue.
• I have provided sufficient information below to help reproduce this issue.

Summary

streamlit is supposed to generate WebSocket ping to ensure that the connection to the end-user is not terminated by any proxy sitting between the user and streamlit

Reproducible Code Example

No response

Steps To Reproduce

1. Build Dockerfile with streamlit==1.34.0 requirements.txt
2. Use ENTRYPOINT ["streamlit", "hello"]
3. Run container, e.g. podman run --rm -p 8501:8501 streamlit
4. Oper browser to localhost:8501, open Network inspector and select WebSocket connection messages
5. Note missing ping messages after initial data transfer over WebSocket

Expected Behavior

In server.py, there is TORNADO_SETTINGS (

streamlit/lib/streamlit/web/server/server.py

Lines 61 to 74 in 406b1e6

	TORNADO_SETTINGS = {
	# Gzip HTTP responses.
	"compress_response": True,
	# Ping every 1s to keep WS alive.
	# 2021.06.22: this value was previously 20s, and was causing
	# connection instability for a small number of users. This smaller
	# ping_interval fixes that instability.
	# https://github.com/streamlit/streamlit/issues/3196
	"websocket_ping_interval": 1,
	# If we don't get a ping response within 30s, the connection
	# is timed out.
	"websocket_ping_timeout": 30,
	"xsrf_cookie_name": "_streamlit_xsrf",
	}

) that states that WebSocket ping messages should be sent every second. This does not occur, and causes the WebSocket connection to be dropped when a component between the end-user and streamlit determines that the TCP connection is idle / not active.

Since this function does not currently work (tested in 1.34.0 of streamlit), deploying streamlit in any environment can cause connectivity issues, unless the developer writes their own ping logic into streamlit.

Current Behavior

No WebSocket ping messages is sent, code suggests it should be sent.

Is this a regression?

• Yes, this used to work in a previous version.

Debug info

• Streamlit version: streamlit, version 1.34.0
• Python version: Python 3.12.3
• Operating System: (python:3 container image, Linux cdf8d47bc708 6.8.4-200.fc39.aarch64 Implement Caching object to support running code blocks only once #1 SMP PREEMPT_DYNAMIC Thu Apr 4 21:00:27 UTC 2024 aarch64 GNU/Linux
• Browser: N/A, but Version 124.0.6367.201 (Official Build) (arm64)

Additional Information

I'm assuming this is a regression or upstream bug as a result of library update.

I've found similar issues and code changes related to this:
#3464
https://discuss.streamlit.io/t/websocketconnection-websocket-onerror/46298/10

[github-actions]

If this issue affects you, please react with a 👍 (thumbs up emoji) to the initial post.

Your feedback helps us prioritize which bugs to investigate and address first.

[toredash]

I'm wondering if this is a upstream bug in Tornado.

I did a TCP dump of the traffic locally where the websocket connection was established via curl, and indeed there is ping traffic being generated:

But the strange thing is that it terminates the connection after 30s, which seems to be a bug in tornado then.

Looking upstream, there seems to be one PR tornadoweb/tornado#3376 that attempts to solve this. I tested with the changes suggested in the PR, and this changes the traffic flow to this:

This works, but for some reason the ping comes at interval of 30s. I think this is related to the PR in question (logic error?)

[vdonato]

Thanks for reporting this @toredash!

Do you happen to remember the last streamlit version where you didn't observe this issue? Anecdotally, I remember inspecting network traffic and seeing websocket pings from tornado to the streamlit client at some point in the past, so there's a chance this is indeed an upstream tornado bug given that I don't think the code for this on our end has changed for quite some time (it has probably been months to years since the code related to this has been changed significantly).

[toredash]

@vdonato I made the assumption that this was a regression, but it seems this problem has been present in earlier builds of streamlit as well. My bad, I've removed that tick.

I noticed the same, that the streamlit code on this area has been stable for some time. For whats it worth, it seems that tornadoweb/tornado#3376 is solving the issue of tornado closing the ws connection prematurely, but with the logic error.