This seems to be happening on phone builds (cordova) as well using mupx.
Some things that may help debugging:
I was having this endless reload problem on both of my dev machines and in production (Galaxy). It happened on every client I tried - iOS app, Android app, Chrome desktop, Safari desktop and mobile, IE, Edge, and Firefox. Iām now using Meteor v1.3.2.4, but this has been happening to me since v1.3 beta 12 (the first of the 1.3 betas I tried).
So, I was poking around some internal packages and saw the reload-safetybelt package. Yeah, sure - I think a safety belt sounds good. Why not? I added it to my project and presto! it fixed my problem. Yay!
Unfortunately, the package is completely undocumented and the code hasnāt been touched since it was written two years ago. Digging into the package, itās pretty simple: if the webapp package isnāt loaded, try again.
if (typeof Package === 'undefined' ||
! Package.webapp ||
! Package.webapp.WebApp ||
! Package.webapp.WebApp._isCssLoaded()) {
document.location.reload();
}
Hope this helps.
Awesome. Some super exciting news if this works. Havenāt been updating my
app due to fear of the infinite reload for users.
This didnāt seem to work for me.
Is it supposed to work on the next update? Or only on future updates?
Did anyone else have success with this method? Sounds like exactly the same problem, but just didnāt do anything for me.
Also, looking at this packageās code. I donāt know how it could work for you. It just adds another case to the reload list. I want to stop reloads happening. Not add more ways my app could reload.
@martijnwalraven could this have anything to do with changes made in Meteor 1.3 with regards to hot code push for mobile?
Yeah, it seems strange that it works for me. I wouldnāt think that another reload would really help things. I figure there must be something in my project that is not right upon initial startup and now gets loaded after this package. Perhaps the reload introduced by this package gives something downstream a chance to load properly. Iām now looking for anything we load from a CDN or other stuff external to the project.
Also, perhaps weāre experiencing separate issues with the same symptom. After all, this happens on both cordova and browser platforms for us.
I donāt like this at all, not knowing what is going on (except that it looks a lot like a race condition). The reload-safetybelt package changed nothing for me, the reload loop still happens intermittently.
@abernix I tried reload-safetybelt when my Chrome browser was looping, with the server running. Adding a package causes a server restart, and after the server restart the looping resumed. I removed the package, which of course again restarts the server and the looping continued. To perform your DISABLE_WEBSOCKETS=true test I needed to stop the server manually, which meant that I had to hit reload in the browser when the server came back up. This time there was no looping. I then stopped the server again, removed the DISABLE_WEBSOCKETS=true env var, and restarted. No looping this time either. So unfortunately this gave no further information. But the intermittent-ness of the issue points to a race condition if you ask meā¦
(Edit: There is actually a tidbit of information there: If a client is stuck in the reloading loop, and the server is autorestarted due to a file change, the looping will resume when the server is back up).
This is a really strange bug.
I have a site running at domain.com and itās exactly the same code and setup. Nginx loading balancing to mupx instances of the app.
I have another site running at sub.domain.com with the same codebase, just slightly different Meteor settings, but here I do experience the infinite refresh bug. Really strange
Ah. This matches my experience exactly.
bar.com -> Ok
foo.bar.com -> Loops intermittently
bar.com/foo -> Loops intermittently
I donāt have the issue with bar.com/foo.
No idea why the subdomain thing would be an issue, any ideas?
Just to be clear, when this happens to me /foo is not a route in the site, it is ROOT_URL=http://bar.com/foo
So, Iām not clear if my suggested solution fixed it or not? You should leave DISABLE_WEBSOCKETS=true in place for a while to debug if you need to. I recommend running it on a staging environment (which should be identical to your production environment), but unless you are running at massive scale, itās unlikely to be noticed even in production if you were to leave it on for a while.
Disabling websockets didnāt solve it for me, Iām using Heroku AND Cloudflare. Anyone else using Cloudflare?
Anyone getting this issue when running a local meteor instance?
I think the only common denominator so far is it happens behind nginx but not when running Meteor http server.
If thatās what you mean by ālocalā.
@abernix I can now confirm that DISABLE_WEBSOCKETS=true does not solve the issue. Reload loop still happens.
Iām not using cloudflare or heroku. On digitalocean.
Has anyone had this issue with Galaxy?
@abernix I have made a file with all the HTTP+WS reqās from a reload loop cycle, including the WS frames. I am non the wiser from looking at it, looks normal to me. If you are interested I can send it to you.
@jesperwe Happy to try to take a look at it you want to post it in a gist, or e-mail me at **redacted**, where ā+ā is ā@ā. 
Would also be helpful to see your nginx.conf.
Iām trying out Galaxy Europe right now, and Iām not having this issue with that setup. Same app.
EDIT:
No. Iām getting the same error on Galaxy after a redeploy.
Is anyone here who is experiencing this altering the cache control headers (i.e. Cache-Control or Expires) in any way? Either at the proxy level (for example by setting Cache-Control or using expires in nginx.conf) or by modifying them in Meteor directly?