This issue seems to happen sporadically with some users.
If you’re in chrome sometimes it never seems to get the new bundle / fresh code.
Using the reload button, shift-refresh or debug mode “empty cache hard reload” does not work.
deleting browsing data just for that server does not work.
deleting everything in chrome does.
if I go into Private browser I see latest code.
Anyone else getting this? Any ideas welcome?
When you are in dev tools in the browser, on the Network tab, what do you see as source for the code? Is is a Meteor server, a CDN url, a Service Worker as size, or a disk-cache?
Thanks, I ended up wiping my full cache,… but will check this next time it happens. For now it’s Meteor server url, when you rollover the size it shows if it’s in cache… one of our colleages it was showing as Memcache.
One of the other colleagues who it was happening to, it not seem to show anything different. I couldn’t convince him to wipe his entire cache, as hew was workaround it via an Incognito window
one of my colleagues worked this out… so seems to be related to localstorage, this worked
previously we were just doing cookies and sitedata… but that did not get those site settings.
That said, I would be interesting to know how we can avoid this.
So, is this an instance of the XY problem? The title says “A few users can’t seem to get new code/bundle” but in the details are that your application stores stuff in localStorage which your application logic does not “upgrade” or “clear” on each code push?
Do you expect Meteor to provide a generic solution to this?
it seems weird that we’d push updated code to a Meteor server and some users seem “cached” on old version. I’d expect the platform to solve this.
We’ve been using MeteorJS for about 10 years… .i’d say this problems only seems to have reared it’s head since move to Meteor 3… but hard to be specific as it’s been so sporadic and there’s a good chance the customers / users would probably never even realize it’s an issue.
My wild guess, is it’s probably this MeteorDynamicImports… “sourcesByVersion”… what does that even do… but sounds like it could cache / use the wrong version?
Every dynamically imported component or file in Meteor stays on the server (out of the main bundle) until required. On the first request, it is being cached on the client because these are POST calls as opposed to GET requests that are used for other resources. POST requests cannot be CDN-ed so better to store this code on the client instead of killing the server with millions of code deliveries.
The small bundles you see in your IndexedDB are generated on the fly with unique names. If you generated a new Meteor bundle, those small bundle names of dynamically imported pieces of code will change name.
This is basically what sourcesByVersion even does.
The type of issue you have is similar to two situations:
When this happens, your bundle version in the Chrome Network tab is the bundle version on the server?
thanks for the explanation.
We are not doing anything explciit like that on caching… just Meteor out of the box. I’ll need to check that next time this happens
Just to confirm, are you using jam:offline, I had similar problems with this package.
nope we’re not using that
Another cause could be service workers with aggressive cache implementation.
we’re not using Service Workers, unless in the underlying Meteor?
No by default Meteor does not use service workers. However, there is the edge case that a previous app on localhost:3000 installed a service worker which is then still running because the scope is still the same for the browser. In that case the sw can make devs think something is broken because it runs with assets and caching rules from an entirely different project.
