Query String Parameters not updated after rerun

[pkubiak]

Summary

When st.experimental_set_query_params call is followed by st.experimental_rerun, updated query params are visible to streamlit (via st.experimental_get_query_params) but browser address bar is not updated.

Use case: Use query params to store dashboard parameters and change them with button click (rerun is required to update dashboard).

Steps to reproduce

Code snippet:

import streamlit as st

params = st.experimental_get_query_params()
st.write(params)

if st.button("Clean"):
    st.experimental_set_query_params()

if st.button("Set with rerun"):
    st.experimental_set_query_params(q="with_rerun")
    st.experimental_rerun()

1. Run snippet
2. Click on 'Set with rerun' button
3. Observe that updated query string is displayed on page but browser address bar is not updated.

Expected behavior:

Query String parameters are updated after executing st.experimental_set_query_params even when st.experimental_rerun is used.

Actual behavior:

Query String is updated somewhere internally (it is visible to streamlit), but the change is not reflected in the browser (in address bar).

Is this a regression?

Probably not

Debug info

• Streamlit version: 1.13.0
• Python version: 3.10.0
• Using Conda? PipEnv? PyEnv? Pex?: No
• OS version: Windows 10; Build 19044.1889
• Browser version: Chrome 106.0.5249.91

Potential workaround

Reset query params on each requests:

params = st.experimental_get_query_params()
st.experimental_set_query_params(**params)

[LukasMasuch]

@pkubiak Thanks for reporting this issue. I was able to reproduce it here. Currently, if the rerun is triggered via experimental_rerun, the query parameter is never actually sent to the frontend.

[blipk]

Doing it like this works for me:

st.experimental_set_query_params(**query_params)
time.sleep(0.1)
st.experimental_rerun()

[pkubiak]

@blipk Thank you, for your answer, it actually solves the problem somewhat, but it seems quite hacky :P

Nevertheless, it directed me to the trail of race condition in the handling of reruns.

---

@LukasMasuch
Application status updates on the frontend are made via websocket messages, sent from the Runtime class.

It iterate over all connected sessions (AppSession instances), check if they have some messages to send, and if so it send them via websocket. Then Runtime fall asleep for 0.01s and repeat checking. (

streamlit/lib/streamlit/runtime/runtime.py

Line 579 in 909d9b8

for session_info in session_infos:

).

On the other hand, AppSession has it own Event Loop, which in case of experimental_rerun handle ScriptRunnerEvent.SCRIPT_STOPPED_FOR_RERUN followed by ScriptRunnerEvent.SCRIPT_STARTED event.

In the code of AppSession we can check that during handling SCRIPT_STARTED event, it clear unprocessed messages queue (

streamlit/lib/streamlit/runtime/app_session.py

Line 471 in 10c677b

self._clear_queue()

), which is responsible for, among other things, deleting the query_string update message.

So there is some race condition between sending messages to client, and clearing queue for new script run, which, in the case of a more heavily loaded server, can cause the unforeseen loss of many queue messages.

We should probably somehow wait until all the messages have been sent, instead of clearing the message queue.

[fplanque]

I am also deeply annoyed by this issue.

[sfc-gh-wihuang]

Hi @pkubiak ,

I just checked this with this app:
https://c38ug7yvnemfeky9xtgulf.streamlit.app/ which uses the latest streamlit code. I was wondering if this issue is fixed from your perpsective? It seems from my perspective, it is but just want to double check.