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]
else:
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.markdown('---')
_ = st.multiselect('Selection 2 - quickly select stuff in here', list('ABCDEFGHIJKLMNOPRST12342567i7oABCDEFGHIJKLMNOPRST12342567i7o') * 3)
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!)
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.
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.
I have noticed similar behavior and with other widgets and ag-grids, the entire page and all widgets reset. It appears to be random and I cannot pinpoint the reason due to the randomness. No one seems to know why this random refresh reset occurs : (
Has anyone made any progress on this, or is there a ticket we can follow for updates? I’m using streamlit 1.17.0 and occasionally encounter this issue when using st.forms, where a handful of dropdown inputs appear to reset after hitting submit.
Thanks for stopping by! We use cookies to help us understand how you interact with our website.
By clicking “Accept all”, you consent to our use of cookies. For more information, please see our privacy policy.
Cookie settings
Strictly necessary cookies
These cookies are necessary for the website to function and cannot be switched off. They are usually only set in response to actions made by you which amount to a request for services, such as setting your privacy preferences, logging in or filling in forms.
Performance cookies
These cookies allow us to count visits and traffic sources so we can measure and improve the performance of our site. They help us understand how visitors move around the site and which pages are most frequently visited.
Functional cookies
These cookies are used to record your choices and settings, maintain your preferences over time and recognize you when you return to our website. These cookies help us to personalize our content for you and remember your preferences.
Targeting cookies
These cookies may be deployed to our site by our advertising partners to build a profile of your interest and provide you with content that is relevant to you, including showing you relevant ads on other websites.