Running my Streamlit application (1.39) in snowflake and it is crashing on a fairly frequent basis with the error:
Failed to process a Websocket message (AxiosError: Request failed with status code 404)
It can happen on any page, at any point in the navigation, and it doesn’t seem to be related to any code or logic on any specific page. After the crash, I have to hit refresh, or back to leave the app, and then reenter the application.
Is anyone else encountering this?
Yes, facing the same issue.
yes, I’m also facing same issue. Any solution for this?
same issue.
Same issue here Connection error
Failed to process a Websocket message (AxiosError: Request failed with status code 404)
Any solutions shared?
Hi, I have the same problem.
The error is caused by an HTTP request, whose path is “/message?hash=…”.
I have the impression that this request is caused by the function “st.rerun” in a certain context.
Yes, I think for me it was from st.rerun within a fragment. I’m using streamlit 1.44.1 now which no longer has the issue.
I removed an st.fragment and integrated it into a normal part of the page, and I haven’t seen this error for a little bit. So, I’d recommend removing whatever fragment is on the page that you’re getting the error on.
Users of my app are reporting this same error, though it’s not every user and it’s not all the time for them. In this app, an st.dialog() is presented to the user for either adding or editing some data, within which the user can save their changes. After the changes are saved, I call st.rerun() to close the dialog programmatically, ensure the data in the UI is refreshed to reflect their changes, as well as other changes that may have been made by other users; this is when the error is shown to them.
I didn’t have the st.rerun() in a try-catch because I didn’t see it as necessary since the app was going to rerun anyways, which resulted in a blank white screen with the error, forcing a manual reload to resolve.
As a temporary workaround until Streamlit can resolve the issue, I’ve added a retry for the st.rerun() call, and if that fails, it simply displays a warning to the user indicating that they need to do one of the following to see their changes:
It states in the documentation for st.dialog() that st.dialog() inherits from st.fragment(), so I can safely assume that this is the same issue you and others are reporting. Let me know if any advances in this are made! I would love to remove this workaround I came up with.
P.S. I tried making the data loading logic in this app cached and writing a cache invalidation method in that class to try and refresh the data manually rather than using st.rerun(), but this doesn’t invalidate the UI elements [obviously] and results in the same behavior where you have to either manually reload or navigate away and come back again. The only way I could think of resolving this would be to use JavaScript to manually crawl through DOM elements, clearing them out, and rebuilding them by calling our render() method, but since this app is a Streamlit-in-Snowflake app, using JavaScript is not an option.
Have been going through the same issue. My app is deployed on snowflake and I use it directly from the snowflake UI. When the same code is duplicated and used as a new app - there are no issues. With the original app - its a hit or miss after multiple full page manual refreshes.
Not sure if this is related or exactly the same but this issue on Github is a similar issue and mentions there is a fix coming. I’ve also been seeing intermittent websocket errors but rolled back to 1.44.1 which is also mentioned on that issue.
Yes, this seems to be a known issue with Streamlit when using st.rerun() inside components like st.fragment() or st.dialog(). Updating to Streamlit 1.44.1 has helped some users resolve the error. As a temporary workaround, try restructuring the code to avoid using st.rerun() within fragments, or handle it with a retry mechanism and user warnings.
Hope this helps others facing the same problem.
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.
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.
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.
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.
