-
-
Notifications
You must be signed in to change notification settings - Fork 26.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Loading chunk XYZ failed (cont.) #6243
Comments
We auto-lock closed issues that haven't had recent activity |
What do you mean with "it still tries to load the old resource"? What kind of behavior do you have in place to prevent users from navigating through an older version of your application? It sounds like the service worker didn't cache all the bundles, resulting an error when the lazy load is triggered and the chunk is no longer available on the server. Perhaps they are too big? See: #3882 (comment) |
Well, nothing in particular. I assume that SW should cache the application as a whole (based on precache-manifest) and not to touch the network. Am I misunderstanding something about this?
I just checked, but none of the file is bigger than 2MB except source maps but those does not matter. The biggest file is like 1.2MB (vendor libraries I assume). It's actually really strange. I just noticed that there were couple of reports from last few days requesting a files that comes from latest release and are still available on the network. Yet this error has occured. The server is a completely static nginx without any sort of caching setup. It feels more like some sort of corrupted SW cache 😕 |
No what you are describing is correct. Maybe I misunderstood you but if you use a service worker users can still be on an older version of your application if they leave the tab open. If the chunk is still present on the server it sounds like a regular network error. How did you gather these error reports? A scenario that’s possible is that a user interacted with your app in a way that triggered the loading of a new chunk while they were offline, resulting in a network error. |
If the SW has cached all resources properly, it shouldn't request network so it's unlikely it was network error due to being offline. It's kinda the main theme of PWA apps to work offline, right? 😄 Besides, if user would be offline, the automated report would not be even received. We are using Sentry to gather automated reports. I went through them and in most cases, the error happens when a user is redirected back to the app after processing a payment by 3rd party site. There are some ugly query params in the URL, so after processing that it does Thinking about it, the replace might happen fairly quickly. What if SW is in middle of checking for a new version? Could that cause some corrupted state where it does not have any resources available? I will certainly try to repro this soon, it's very odd for sure. |
Have you made any progress on replicating it? I would be really interested if you can find some way to replicate this. I have not been able to get it replicated with any sort of certainty. The last week and a half I have been chasing down why the SW is sometimes loading old content even though I watched it in the network tab just download the latest changes. Its worked fine for over a year now and now for some reason some users randomly get the previous builds index.html which points to the old builds bundle when they refresh after new content is available. Its weird because I can see that its caching the right resources but that first refresh uses the old build's index.html for whatever reason. Subsequent refreshes it loads the appropriately cached resources including the chunks it downloaded. Its an odd one. |
I think I'm having this same exact issue. However, the only time I see the issue is when I launch my PWA in standalone mode on an iPhone. If I open my app in the browser on my phone, it works fine. But when I try to open in standalone mode I am faced with just a white screen. When I open the console I see that I'm getting a 404 trying to load a chunk, however that chunk is from 3 deploys ago... The only way for me to fix this is to command + option + R in the developer tools on my mac, connected to my iPhone. But even then, on the next reload the issue persists. Edit: If this is indeed the same issue, I was able to fix this by manually deleting all the website data for my application on my phone. I'm not sure why this would fix the issue, but the command + option + R didn't, thats the only reason I wasn't convinced that it was a cache issue in the first place. |
I think you guys are facing some different issue. In my case, it's not fetching old content, but it actually tries to grab the one that's present on the server. For some strange reason, it ends up with the error anyway. It's totally possible it's a bug in a Workbox itself as CRA itself doesn't do that much. I still haven't got to replicate this, I am too swamped with other stuff. Hopefully, next week :) |
Okay, I can reproduce my issue very easily. After I make any changes to my application and deploy to gh-pages, the issue arrises. My app does not work until i clear the browser cache on whatever device I am using. I have tested this in Google Chrome and Safari - on iOS and MacOS. If i should open a different issue to report this problem please let me know, this issue makes it impossible for me to push changes to my app as most users can't know to manually clear their browser cache. Let me know if there is anything else i can provide to help work on this issue. |
This issue has been automatically marked as stale because it has not had any recent activity. It will be closed in 5 days if no further activity occurs. |
This issue has been automatically closed because it has not had any recent activity. If you have a question or comment, please open a new issue. |
The original issue got locked for some reason.
I thought that with Service Worker in place, this error will be finally gone. Unfortunately, in some cases, it still tries to load the old resource. There is definitely less of these errors compared to a situation before doing this.
The Firefox 64.0 is common for most of these issues, but there is some Chrome 71 as well, so it's probably not browser related. It's widespread over pretty much all major OS.
I haven't seen any errors related to installing Service Worker.
I will try to reproduce it locally soon, but I am opening issue now in case someone has an idea what might be wrong.
The text was updated successfully, but these errors were encountered: