Improvements to the axis configuration for built-in charts (#5412).
Memo and singleton improvements: support text values for show_spinner, use datetime.timedelta objects as ttl parameter value, properly hash PIL images and Enum classes, show better error messages when returning unevaluated dataframes (#5447, #5413, #5504, #5426, #5515).
Zoom buttons in maps created with st.map and st.pydeck_chart use light or dark style based on the app’s theme (#5479).
Websocket headers from the current session’s incoming WebSocket request can be obtained from a new “internal” (i.e.: subject to change without deprecation) API (#5457).
Improve the text that gets printed when you first install and use Streamlit (#5473).
I tried to deploy an app with this new version in Google App Engine with no luck. The app page only showed “Please wait…”.
The logs showed the error about “server.enableCORS=false”:
Warning: the config option 'server.enableCORS=false' is not compatible with 'server.enableXsrfProtection=true'.
As a result, 'server.enableCORS' is being overridden to 'true'.
In order to protect against CSRF attacks, we send a cookie with each request.
To do so, we must specify allowable origins, which places a restriction on
cross-origin resource sharing.
If cross origin resource sharing is required, please disable server.enableXsrfProtection.
So I tried to disable the server.enableXsrfProtection and others solutions after searching, but had no success.
I was able to solve the problem by downgrading streamlit version to 1.13.0.
Hey @caioneves, thanks for the report - and what a pain!
It sounds like this might be a regression, though we’re not (yet) able to repro it. To help us diagnose, could you re-upgrade to Streamlit 1.14 and paste us the contents of your browser’s developer console output after you hit the “Please wait…” message?
I’m wondering if we’ll see an uncaught exception, or other error, being logged in the console that could help us track down what’s going on.
Another notable change is the multi-select will remain open even after you select an option. A further improvement would be to retain the state of the search input/filtered list and after selecting the remaining options not only keep the multi-select open but keep the filtered list in view as well.
(TL; DR version - we’ll have a patch out fixing this in the next few days, likely early next week to avoid releasing a patch too late in the week)
I managed to track down the root-cause of the issue, which is that one of my recent changes made things so that the web client always does a healthcheck on the server before trying to establish its websocket connection. Previously, it just attempted to establish the websocket connection without knowing whether the server is healthy.
I’m fairly certain that /healthz has actually always been broken in Cloud Run / App Engine (due to the endpoint name being reserved), but it previously wasn’t an obvious issue because it only got pinged if the client lost its websocket connection. At that point, you’d see the same behavior that you’re running into now since the /healthz checks are guaranteed to fail, but it’d only be mildly annoying because a page refresh would fix it.
The good news is that we’re finally going to rename these endpoints in a few months (it’ll take awhile before we can do it because a few other non-open source teams rely on the /healthz endpoint of apps, so we’ll need to coordinate the switch), but in the meantime I’ll have a temporary fix out for this shortly.
Update: PR containing a fix is open in
I’ll update this thread again once 1.14.1 is released.
Just noticed a glitch with plotly charts after upgrading to 1.14.0: If a plotly chart (rendered with st.plotly) is expanded and then reduced, it doesn’t reduce to its original size. I’ve added screenshots with an example. This works fine in 1.13.0.