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.
