I’ve found strange behaviours with st.session_state. What happened to me was that it seems like when two users are using the web app at the same time, saved session states from one user activity interfere with the other user activity. Is it normal? And how should this be avoided?
Hi @PaleAlex, this shouldn’t happen, since each user should have their own session. Could you share a simple reproducible example where you think this might be happening?
thanks for your answer. I am attaching a screenshot.
Short story of the app and of my use of session states
I am sorry the app it’s not in English but I will try to explain it in short.
The app suggests the best restaurant in any italian city the user is looking for. I wanted the suggestion to change only when the user changes both city and province and for this I create a session state (city, province) in order to save the first state and check when it changes.
Coming to the point
I am opening two different chrome tabs (from the same PC) and I am running the streamlit app in both.
Right side tab. Looking for city = Pesaro, province = PU. Here it is saved the session state (Pesaro, PU)
Left side tab. Looking for city = Ferrara, province = FE. Here it is saved the session state (Ferrara, FE)
So far so good. Now what is unexpected:
Left side I am changing the city from Ferrara to Livorno. The suggestion changes right away, going to Pesaro (the city saved in the session state of the right side tab), but expecting, firstly, not to change, or in case to change with Livorno…
In any case, I think at the end I am going to change the code using a form component instead of session states.
Hi @PaleAlex, I spoke with a few others internally, and consensus was that we all agree this shouldn’t happen – each browser tab should have a separate session state.
We also weren’t able to reproduce this with a simplified app. For example, I tried opening this app in two separate tabs, and going back and forth, and wasn’t able to find a case where the state of one seemed to influence the other
import streamlit as st
st.selectbox("Choose name", options=["Name1", "Name2", "Name3"], key="name")
st.write(st.session_state)
st.button("Rerun")
Could you try to whittle your code down to the bare minimum that still shows the issue, and then share that simplified code?
Here below a snippet of the code. I first take the inputs and save them in session states. Then I check for them and if they have been changed I update them.
city = st.text_input('Città', placeholder="e.g. Ferrara", key = "field").capitalize()
province = st.text_input('Provincia (sigla)', placeholder="e.g. FE", max_chars=2).upper()
state = "Italia" #st.text_input('Stato', placeholder="e.g. Italia").capitalize()
border = st.selectbox("Confine di ricerca", ("comune", "provincia"))
if "border" not in st.session_state:
st.session_state["border"] = border
if "geo" not in st.session_state:
st.session_state["geo"] = (city, province)
#doing things not related with session states
if border != st.session_state["border"] or (city != st.session_state["geo"][0] and province != st.session_state["geo"][1]):
#doing other things not related... and finally update session states
st.session_state["border"] = border
st.session_state["geo"] = (city, province)
The web app is active at choosing.club. Eventually you can try from there, opening two tabs of Chrome, logging in with a pseudo mail (mail@mail.com), and repeating my experiment I reported in:
Hi @PaleAlex, I wonder if some of the complexity is happening in the “doing other things unrelated” code. It’s difficult to say for sure. But, one very simple test is to add a line to your script that does st.write(st.session_state), and see if the session state of one tab affects the session state of the other. I tried using your simple example, and didn’t find any case where the session state of one affected the session state of the other, but it could at least provide more visibility into what exactly is happening.
thank you for your answer. It’s really strange. I will surely try to figure it out writing down session states. I also noticed that I was not able to reproduce the issue with two tabs of different browsers (edge and chrome).
For now, thank you for assisting me. Will let you know if I find something.
Not sure what you are after. Yes, module-level state is shared. The cache generated by cache_data and cache_resource is shared. External resources are shared too. There are many ways to have shared state.
I have the same issue in my app. I have a page where the users’ favourite items are saved so they can easily select them throughout the app, but for some reason when someone else uses the app their favourites are displayed in my application, and so the feature doesn’t really work.
I’m not sure how to reproduce, as it is only sometimes that this is happening…
I work with streamlit 1.40.2, did not implement any caching (except st.fragment decorators), have containerized the app and host it myself. I have also implemented supabase.com authentication and streamlit cookie manager from the community to automatically reauthentificate users.
– All works well!
However, when another user visits the page (from another device! other location!) they see the dashboard of the currently logged user. As a matter of fact in my case, they get automatically authenticated too …
– What a mess!!!
My app actively uses session-state to store user IDs and other data to work across multiple streamlit pages. I hope streamlit server can handle multiple user session congruently . Any ideas what goes wrong here?
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.