Bug causing widget reset

We have recently come across a weird bug in streamlit that we haven’t been able to fully understand.

Overall, it looks as if the app widget states get reset while some heavy computation takes place.
We tried to come up with a minimal example (and a video in order to show the behavior).


If a user clicks makes a lot if quick selections in Selection 2, they will likely trigger some sort of general reset and all the previous selections will be lost. In other words, state is not preserved anymore.

Below is the code for the minimal example. Any help would be appreciated it. This bug has been very troubling.

def genprimes(limit): 
    # just generate some heavy load function
    D = {}            
    q = 2

    while q <= limit:
        if q not in D:
            yield q
            D[q * q] = [q]
            for p in D[q]:
                D.setdefault(p + q, []).append(p)
            del D[q]
        q += 1

def non_cache_wrap(limit):
    return sum(list(genprimes(limit)))
import random

non_cache_wrap(random.randint(100000, 1000000))

# select the spend sub type
sel1 = st.selectbox('Selection 1 - Change this to make sure you see the break', ['A', 'B'])

_ = st.multiselect('Selection 2 - quickly select stuff in here', list('ABCDEFGHIJKLMNOPRST12342567i7oABCDEFGHIJKLMNOPRST12342567i7o') * 3)

I can confirm the glitch with local run of version 1.9.2

Update: Managed to reproduce this behavior in every version starting with 0.89.0

1 Like

I also managed to reproduce this building that file in a docker container with python 3.7, streamlit 1.10.0, and protobuf 1.19.0.

Checking on what Andrii mentioned above, I could not replicate with streamlit 0.83.0.

I have now seen this happening a lot, especially in somewhat larger dashboards and it can be fairly frustrating to get back to the original point.

Does anyone have any ideas here?

1 Like

Just deployed on streamlit cloud: https://share.streamlit.io/jonasharnau/streamlit_break_app/app.py

Breaks almost immediately for me there as well.
Underlying repo is here.

There is also a github issue opened here: Widget Reset on heavy calculations · Issue #4836 · streamlit/streamlit · GitHub

Probably related is also this issue: click

Tagging @randyzwitch since this seems to both be an issue that is replicable even on streamlit cloud and I expect will have wider impact there and also an issue that has a massive impact on a large number of our applications at the moment - truly appreciate any guidance here! (Thank you!)

Hey everyone!

We’ve been troubleshooting this, and our repro is not 100% reliable, so it will take some time to investigate. We have found out that this bug occurs prior to 1.10. We can successfully repro it in 1.9.0 (I would be curious on how successful @Andrii_Borodin was in reproducing beforehand). We think a race condition is being hit here where Streamlit returns back with information that is out of date due to follow-up rapid requests to Streamlit.

We have been testing whether the config option runner.fastReruns equal to true would mitigate this issue and might be a valid workaround. We have not enabled this by default to enable more testing on this, but it might handle the use case of a rapid events being sent to the Streamlit server much better. I’m curious if you are able to reproduce this issue with this option config set. You can set this in config.toml file. This might help us understand if we have a good workaround. See our documentation on how to set configuration options.

Thank you so much in your help with this!

To reproduce this behaviour I have used same code provided above. In order to reproduce it select B in first input (just to see that it is changed) and then quickly change input in multiselect. Usually I just left-click on input and then fast click Enter|Return (this will add next parameter in multiselect). With older versions it require more iterations to reproduce the issue. App broke on each version till I reached 0.88.0. After that I could not break it.

In a nutshell - quick change state of multiselect (can use auto-clicker to create additional load). Sometimes it took up to a minute to break the app.

Can you use a form to work around this issue?

Could you please clarify your question?