I haven’t used my app in a while so it went to sleep and needed a wake up. After it woke up, I saw the error:
TypeError: Failed to fetch dynamically imported module:
https://xxxx.streamlit.app/~/+/static/js/index.DzWF7M_0.js
I did not update code since my last visit so I expect it to continue working without any issue. It’s a simple app without any fancy bells and whistles. And it is private data so I can’t share the URL.
The app does work eventually after I hit “Reboot” a few times. But it also keeps failing unpredictably with a similar error. Is there some kind of cache that I need to clear? If so, where is it and how can I clear it?
Hi, I have been seeing the same error on a few different apps over the last week or so. It takes several refreshes for the error to go away. It also takes quite a long time for the app to start up, and that usually requires at least one refresh as well. These apps were booting up fine about 2 weeks ago and the code hasn’t changed.
Here are the contents of requirements.txt files for 2 of the apps: App1:
google-generativeai
streamlit
Pillow
pytesseract
I am also seeing this issue lately. My requirements:
streamlit
watchdog
streamlit-extras
plotly
scipy
# 23-12-12 until at least 24-10-04: StreamlitAPIException: Streamlit only supports Bokeh version 2.4.3, but you have version 3.3.2 installed.
bokeh==2.4.3
The value after static/js/index. varies, we’ve also seen CbuYSrVP.js.
Unfortunately, we have not been able to reproduce the problem. Is this possibly an issue with either deploying a new version of our app, or specifically deploying a new version of our app with an updated version of streamlit?
Having the same problem. This happen very often in random place
Our reserch: this problem appears in chromium browsers only. Looks like it concerns the next problem: there is limit of loading resources per page, The socket pool has a limit of 6 sockets per host, but certificate errors always make two connections in a row. First they get a certificate error, then they add the certificate to allowed_bad_certs and retry, so browser infinite loop until the requests get aborted.
for more info here Chromium
The issue occurs in case of self signed certificate only.
The questions - is it possible to reduce number of resources streamlit loading? it will fix the problem.
By the way, we have to use self signed certificate only only because of another bug - it is not possible copy/past into data_editor without it, if it is not a localhost! That’s also big streamlit problem
Please, help!
I was having the same issue with my app and to me this seems to be a browser cache related as when I try the app with incognito mode, I do not get this error after seeing it in the normal browser mode.
It seems like this happens with just Date or Time type fields in my case. Is that consistent with what others are experiencing?
I didn’t restart the app at all. Simply switching to incognito mode after getting the error on normal mode worked for me.
I wonder if there is a way to enable config within app to bypass browser cache and if that is a good approach to solve this.
Any pros / cons that you all can think with this approach?
UPDATE: Confirmed this is a browser cache issue as after clearing the cached files and images, the functionality returns to as expected in the normal browser mode.
An update on my earlier comment. We recognized that this was being caused by rate-limiting in the NGINX server that is proxying requests to our streamlit server. Streamlit is issuing many requests to get these chunked assets, thus tripping the rate-limiting. We relaxed the limits and avoided the issue now.
On the note of caching, we were able to replicate the issue in a private window with no caching, at least in our case.
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.