[1.7-rc.3] Infinite page reloading on deployment

[lmachens]

#9826 (comment)

I deployed 1.7-rc.8 and it ends in inifite page reloading. It triggers_onMigrate on every reload.
It doesn't happen in dev (Windows 10) even with --production flag.

Deployment: project-vmzuyfofjc.now.sh
I deployed it with meteor now and used node-8.11.2-rc.1.
node-8.9.4 has the same effect, so it is not related to the node version?
node-8.9.4 is working fine with Meteor 1.6.1.1.

[crapthings]

same here on ubuntu

don't know how to reproduce. will try

[lmachens]

Same issue with rc.8 (I updated deployment url of first post)

[lmachens]

Looks like it happens when the ROOT_URL is different than the deployment url.
I can reproduce in dev when changing the ROOT_URL to something else (not http://localhost:3000).

[lmachens]

Now I understand what is going on. If I have ROOT_URL set and access the new deployment from a different URL, it will try to load the new version from the old deployment which is deployed on ROOT_URL.
This ends in a never ending loading loop because it will always have a different hash then in the autoupdateVersion of __meteor_runtime_config__ served by the new deployment.
I am only wondering why it was not an issue in Meteor 1.6.1 for me?

I need to access the deployment from different URLs to make sure that the deployment is working fine before I change the alias in now.

When I take a look at recent changes of URL handling (5f131ff and 6c91a4f), it should be fine for me to remove the ROOT_URL because it will fallback to location.host.

[lmachens]

Ok, it is not possible to avoid setting a ROOT_URL:

> [1] Error: Must pass options.rootUrl or set ROOT_URL in the server environment
> [1]     at Object.Meteor.absoluteUrl (packages/meteor.js:1333:11)
> [1]     at email_templates.js (packages/accounts-password/email_templates.js:23:20)
> [1]     at fileEvaluate (packages/modules-runtime.js:339:7)
> [1]     at require (packages/modules-runtime.js:238:16)
> [1]     at /usr/src/app/bundle/programs/server/packages/accounts-password.js:1325:1
> [1]     at /usr/src/app/bundle/programs/server/packages/accounts-password.js:1331:3
> [1]     at /usr/src/app/bundle/programs/server/boot.js:411:36
> [1]     at Array.forEach (<anonymous>)
> [1]     at /usr/src/app/bundle/programs/server/boot.js:220:19
> [1]     at /usr/src/app/bundle/programs/server/boot.js:471:5
> [1]     at Function.run (/usr/src/app/bundle/programs/server/profile.js:510:12)
> [1]     at /usr/src/app/bundle/programs/server/boot.js:470:11

So this is still an issue.

[filosof86]

Hi there,

The same issue for me.

Version: METEOR@1.7.0.1

The production app is constantly being reloaded showing the following message on Dev Console -> Application tab

meteor_reload {"data":{"reactive-dict":{"dicts":{"session":{}}}},"reload":true}

This worked well for Meteor 1.6.x and the issue started to be observed straight after the update to 1.7. Nothing was changed on my side.

Can you please take a look at this since we just can't run our production installation without rolling back to the previous version. In turn, the 1.6 version had an issue with MongoDB reconnection ( e.g. #9962) which was the reason for us to update.

TIA

[filosof86]

Hi,

Has anybody found the reason for such a behavior? Any workarounds?

[lmachens]

It happens when the ROOT_URL points to a different deployment.
Example:
You deployed v1 on example.com.
Now you deploy v2 on v2.example.com with ROOT_URL=example.com, because you want to test the deployment first before changing the alias.
Now the dynamic-import connects to the old deployment and tries to update, but it will always update to the old version and will never end trying again. And it is possible that you get CORS issues. See https://github.com/meteor/meteor/pull/9942/files#diff-9101f5ff2815f508b49f8c7dbdc85299R122.
When you change the alias of example.com to the v2 deployment, dynamic-import will upload to the correct version.

Workaround (client):
Meteor.absoluteUrl.defaultOptions.rootUrl = location.origin;
dynamic-import will now always connect to the same location and not to the ROOT_URL.

In general I think the concept of ROOT_URL is confusing and error prune if you have multiple domains and don't want to change the alias right after the deployment.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale]

This issue has been automatically closed it has not had recent activity.