Web socket disconnection in 1.38.0 problematic in mobile

Using Streamlit
, ,
1

We have a Streamlit LLM chat app using st.chat_input and st.chat_message. In 1.37.1 after a websocket disconnect-then-reconnect the chat conversation was wiped. Not ideal, but predictable. In contrast, in 1.38.0 users see the Assistant’s last message from the conversation pre-disconnect. However, if, following a reconnect, they try to continue the conversation by typing a response to the Assistant’s previous answer, the whole chat history is wiped.

I’m also occasionally getting the race condition problem Bad message format, tried to use SessionInfo before it was initialized

I know that in 1.37.1 a disconnect-reconnect triggered a complete re-run and now in 1.38.0 that only happens where there an running script that was interrupted, but even in that latter case (e.g. if we have an infinite timer loop) 1.38.0 behaves differently as described.

It’s also confusing that in both 1.37.1 and 1.38.0 disconnect-reconnect does not seem to wipe all data - it seems that selectorbox selections are preserved.

We’ve assumed this is a websocket issue because it happens on mobile devices when a) they are briefly in airplane mode and b) tabs are ‘slept’ by the browser after e.g. 3 mins of inactivity.

2

Hi Mike,

We have a Streamlit LLM chat app using st.chat_input and st.chat_message. In 1.37.1 after a websocket disconnect-then-reconnect the chat conversation was wiped. Not ideal, but predictable. In contrast, in 1.38.0 users see the Assistant’s last message from the conversation pre-disconnect. However, if, following a reconnect, they try to continue the conversation by typing a response to the Assistant’s previous answer, the whole chat history is wiped.

This behavior is expected if you are saving the chat conversation into session-state and the disconnect lasts for a longer time. Previously, the session state was cleaned up immediately, but in 1.38.0 we preserved the state for at least 2 mins so that if the websocket session is reconnected within that time the state will not be lost. If you are interested in adjusting this behavior – either to preserve the state for longer, or to clear it immediately and return to the previous behavior then you can configure this by setting server.disconnectedSessionTTL (timeout in seconds, default = 120) which will be available in version 1.39.0 or immediately in streamlit-nightly [see this PR] .

I’m also occasionally getting the race condition problem Bad message format, tried to use SessionInfo before it was initialized

Can you provide more details on when you encountering this error? This is while using 1.38.0, correct?

It’s also confusing that in both 1.37.1 and 1.38.0 disconnect-reconnect does not seem to wipe all data - it seems that selectorbox selections are preserved.

For simpler widgets like these, the state is stored in the client end and sent down with the re-run request so the state is not affected by the session-state cleanup.