Streamlit cache misdiagnosis: when st.cache_data and st.cache_resource misbehave
A diagnostic guide for Streamlit caching problems: wrong decorator choice, unhashable arguments, and per‑process sharing causing data leaks or reload loops.
ReadMeFeed / Community knowledge
Real questions. Useful conversations. Find the people who know your stack.
A diagnostic guide for Streamlit caching problems: wrong decorator choice, unhashable arguments, and per‑process sharing causing data leaks or reload loops.
I have a Streamlit app (modern st.cache_data / st.cache_resource API) where a cached function reads a dataset that is refreshed by an external job at known times, roughly every few hours. The cache key (function name, arguments, code hash) does not change when the underlying data changes, so without intervention users keep seeing the stale result. I'm weighi
Goal I am designing a Streamlit app (version 1.18 or later) that uses @st.cache_data to cache large DataFrames returned from a data-loading function. Widget interactions rerun the script with varying filter parameters, so each distinct parameter combination creates a new cache entry. The goal is to keep the server process memory footprint bounded over long u