meteor 🚀 - Hot Code Push broken on iOS

Same issue, it stops working every time we update font files. Same error message as in https://github.com/meteor/cordova-plugin-meteor-webapp/issues/56.

dovydaskukalis on 13 Oct 2018

Right now we need to release a new app version on font updates.

menelike on 15 Oct 2018

I was about to post a separate bug report, but ours seems like it could be the same issue. I'll post our details below. We are eager to see this working and willing to help out however possible. Thanks!

We are having some issues with Hot Code Push. In short, we are deploying to Galaxy using a Windows PC. We use that same PC to build the Android/Cordova apk. Hot Code Push works for these Android clients. Hot Code Push doesn't work, though, for iOS clients -- the iOS client is built on another machine. We are using the METEOR_CORDOVA_COMPAT_VERSION system, so it should work, from my understanding. There are no apparent error messages (maybe I'm not looking in the right place), but when I redeploy a new app version to Galaxy, only Android clients process the update. Thanks in advance and please let me know how I can help further.
The long version...
We are deploying from a Windows machine to Galaxy using the following commands:

SET DEPLOY_HOSTNAME=galaxy.meteor.com
SET METEOR_CORDOVA_COMPAT_VERSION_ANDROID=v0001
SET METEOR_CORDOVA_COMPAT_VERSION_IOS=v0001
meteor deploy appname.meteorapp.com --settings settings.json --mobile-server=https://appname.meteorapp.com

The hot code push version number is confirmed to be making it to the Galaxy server; we can see the file http://appname.meteorapp.com/__cordova/manifest.json is visible and contains the entry:
"cordovaCompatibilityVersions":{"android":"v0001","ios":"v0001"}

We are building for iOS App Store with the following command:
METEOR_CORDOVA_COMPAT_VERSION_IOS=v0001 meteor build build_directory --server https://appname.meteorapp.com

After building, we open the build in XCode, create an archive, and upload the archive to the App Store for approval and release.
(please PM me for the actual appname, thanks!)

fizx1 on 15 Oct 2018

Anybody figured how to workaround this bug?

rj-david on 25 Oct 2018

We haven't tried it yet, but you could try doing all the builds on the same
machine. It's a long shot.

On Wed, Oct 24, 2018, 8:42 PM rj-david notifications@github.com wrote:

Anybody figured how to workaround this bug?

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/meteor/meteor/issues/10277#issuecomment-432874511,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AReKdBiyQ15zhK3vEuU9nVfYtFX08FB5ks5uoQj5gaJpZM4Xakek
.

fizx1 on 25 Oct 2018

@fizx1 We always deploy from the same machine and manually specify compatibility version in config file, same issue.

dovydaskukalis on 25 Oct 2018

Same issue here. I have an app deployed on heroku, and when I build for iOS, HCP seems to be broken. I have seen a few messages regarding this “bug” on other forums but no real explanation.

`2018-10-18 12:40:36.942203+0200 Premia[1933:140955] Serving asset bundle version: 3e53d8a74f99d185edd94272536b033999610f80

2018-10-18 12:40:39.200604+0200 Premia[1933:140955] Start downloading asset manifest from: manifest.json -- https://premia.herokuapp.com/__cordova/

2018-10-18 12:40:40.369383+0200 Premia[1933:141234] Downloaded asset manifest for version: 9c4c53cdc986cd3eb49b9f99b097a1bb76305b42

2018-10-18 12:40:40.370495+0200 Premia[1933:141234] Download failure: Skipping downloading blacklisted version

2018-10-18 12:40:40.374600+0200 Premia[1933:140955] ERROR: {"line":36,"column":30,"sourceURL":"http://localhost:12224/plugins/cordova-plugin-meteor-webapp/www/webapp_local_server.js"}`

sugoke on 25 Oct 2018

@benjamn, we would like to ask some guidance regarding this?

@RealHandy seems to have some clues on what's happening here: https://github.com/meteor/cordova-plugin-meteor-webapp/issues/56

rj-david on 26 Oct 2018

Just saw these related PRs - hope they made it to 1.8.1.beta soon

https://github.com/meteor/cordova-plugin-meteor-webapp/pull/61
https://github.com/meteor/cordova-plugin-meteor-webapp/pull/62
https://github.com/meteor/meteor/pull/10219

rj-david on 2 Nov 2018

👍3

I am seeing the same issue on 1.7.0.4 with METEOR_CORDOVA_COMPAT_VERSION_IOS in use, its ignoring it even though what is listed on the manifest is accurate. I might role back to see if that helps, but it's starting to get costly rolling out small fixes via app store updates.

Wade-BuildOtto on 14 Nov 2018

The PRs related to the cordova-plugin-meteor-webapp has been merged to master! Wohoo!

For those who wanted to follow the PR for the main meteor project related to HCP and other cordova stuff, subscribe to this PR:
https://github.com/meteor/meteor/pull/10339

rj-david on 16 Nov 2018

BTW, this is also issue #10181. See https://github.com/meteor/cordova-plugin-meteor-webapp/pull/59 for the PR. The code there works if you need it right away, but it was done in a way to highlight the problem for determining a proper fix, which @benjamn is now doing (yay!).

RealHandy on 16 Nov 2018

has anyone tried meteor update --release 1.8.1 to see if the update fixes the issue.

"Not it."

Wade-BuildOtto on 21 Nov 2018

any movement on this?

Wade-BuildOtto on 30 Nov 2018

Interestingly, the problem occurs only when deployed (to Heroku) on my side. On localhost, HCP works. 1.8.0.1 did not fix.

sugoke on 1 Dec 2018

I can also confirm that this is completly broken on IOS.

I get the error

Error: Could not link to cached asset: Error Domain=NSCocoaErrorDomain Code=516 "“315ECD_9_0.ttf” couldn’t be linked to “webfonts” because an item with the same name already exists." UserInfo={NSSourceFilePathErrorKey=/var/mobile/Containers/Data/Application/239C2D9C-6CF1-4DF0-9964-B63372F459CA/Library/NoCloud/meteor/PartialDownload/app/webfonts/315ECD_9_0.ttf, NSUserStringVariant=(
    Link
), NSDestinationFilePath=/var/mobile/Containers/Data/Application/239C2D9C-6CF1-4DF0-9964-B63372F459CA/Library/NoCloud/meteor/Downloading/app/webfonts/315ECD_9_0.ttf, NSFilePath=/var/mobile/Containers/Data/Application/239C2D9C-6CF1-4DF0-9964-B63372F459CA/Library/NoCloud/meteor/PartialDownload/app/webfonts/315ECD_9_0.ttf, NSUnderlyingError=0x2812c3c90 {Error Domain=NSPOSIXErrorDomain Code=17 "File exists"}}

and i definitly did not add any assets!

macrozone on 13 Dec 2018

Interestingly, the problem occurs only when deployed (to Heroku) on my side. On localhost, HCP works. 1.8.0.1 did not fix.

yes, on develop it works, but not once you deployed it.

macrozone on 19 Dec 2018

I upgraded from 1.6 to 1.8, and HCP didn't work even though I used the compatibility override. I had to immediately rollback.

Is this the correct issue for what I experienced?

bmanturner on 19 Dec 2018

I upgraded from 1.6 to 1.8, and HCP didn't work even though I used the compatibility override. I had to immediately rollback.

Is this the correct issue for what I experienced?

yes, i think so. I noticed too late and can't roll back easily now :-(

macrozone on 19 Dec 2018

That's unfortunate... I had a huge mongo migration (servers and schemas) as a part of this deployment, so luckily I was able to revert the merge and go back to using the old mongo instance.

On Dec 19, 2018, at 9:40 AM, Marco Wettstein notifications@github.com wrote:

I upgraded from 1.6 to 1.8, and HCP didn't work even though I used the compatibility override. I had to immediately rollback.

Is this the correct issue for what I experienced?

yes, i think so. I noticed too late and can't roll back easily now :-(

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.

bmanturner on 19 Dec 2018

Did Meteor team comment on that?

It is quite an important feature of the framework.

Le 19 déc. 2018 à 16:45, Brendan Turner <[email protected]notifications@github.com> a écrit :

That's unfortunate... I had a huge mongo migration (servers and schemas) as a part of this deployment, so luckily I was able to revert the merge and go back to using the old mongo instance.

On Dec 19, 2018, at 9:40 AM, Marco Wettstein <[email protected]notifications@github.com> wrote:

I upgraded from 1.6 to 1.8, and HCP didn't work even though I used the compatibility override. I had to immediately rollback.

Is this the correct issue for what I experienced?

yes, i think so. I noticed too late and can't roll back easily now :-(

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHubhttps://github.com/meteor/meteor/issues/10277#issuecomment-448641012, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ANFS1VoHWwKKYqKQ9RS20b6Ir0jbH8Mcks5u6l79gaJpZM4Xakek.

sugoke on 19 Dec 2018

Yes, this is all the same issue: see also #10181. The underlying issue is at https://github.com/meteor/cordova-plugin-meteor-webapp/issues/56

Note: I've just uploaded what I think is an improved workaround: meteor/cordova-plugin-meteor-webapp#59

Update: I have provided in the PR (see link above) some instructions on how to implement this.
If you know how to get the forked PR version, put it on your local drive, and make that the version in your project, you can use this to fix the problem, but it does require that you push a new iOS version out to users with the fix in it.

RealHandy on 19 Dec 2018

@RealHandy So there is no way to update a server from 1.6 to 1.8 without also publishing client updates to the app stores? I've never had to do that when upgrading meteor in the past.

bmanturner on 19 Dec 2018

@bmanturner This bug is related to changes to assets. If the upgrade causes some asset change, then the bug will bite you on iOS and hot code push will fail (as described in the posts across the various related issues and as seen in @macrozone's post above (https://github.com/meteor/meteor/issues/10277#issuecomment-446917778). If HCP is failing, the workaround can only be applied by an update to the user's phone version, since the bug fix is in cordova code.

For example, "webfont.ttf" is in my /__cordova/manifest.json file twice. See the difference between the two lines in bold:

{"path":"packages/fortawesome_fontawesome/upstream/fonts/fontawesome-webfont.ttf","where":"client","type":"asset","cacheable":false,
"url":"/__cordova/packages/fortawesome_fontawesome/upstream/fonts/fontawesome-webfont.ttf",
"size":138204,"hash":"ae832c436a36bdb3b60c1a7fcab1349fd9a5e3d8","sri":"a+iafir/sdUB+O+VSL7/Xlb6AA45KL4fOfmsaW9Nvm1qkIgx3P+L0R6Lw4OTTLMordHfCo6rty9ZhAq8xAyBig=="},

{"path":"packages/fortawesome_fontawesome/upstream/fonts/fontawesome-webfont.ttf","where":"client","type":"asset","cacheable":false,
"url":"/packages/fortawesome_fontawesome/upstream/fonts/fontawesome-webfont.ttf",
"size":138204,"hash":"ae832c436a36bdb3b60c1a7fcab1349fd9a5e3d8","sri":"a+iafir/sdUB+O+VSL7/Xlb6AA45KL4fOfmsaW9Nvm1qkIgx3P+L0R6Lw4OTTLMordHfCo6rty9ZhAq8xAyBig=="},

This is causing the HCP failure, and you need the workaround to get past the failing behavior caused by these assets being in the manifest twice.

RealHandy on 19 Dec 2018

Fix to iOS HCP has been committed. Excited to test this early next week

https://github.com/meteor/meteor/pull/10248#issuecomment-453613510

rj-david on 11 Jan 2019

Note: to test these changes, you'll need to run meteor update --release 1.8.1-beta.13 first.

Thanks especially to @RealHandy for finding an elegant solution! https://github.com/meteor/cordova-plugin-meteor-webapp/pull/59

benjamn on 11 Jan 2019

👍1

Thanks @benjamn and @RealHandy. Great way to start 2019. Hope for the stable release of 1.8.1 soon

rj-david on 12 Jan 2019

I deleted my previous replies due to new data we collected

Confirming that Hot Code Push now works with iOS with one caveat. There is a need for a complete uninstall of any version of the app running previous versions of Meteor with the HCP bug. When we tried updating an existing iOS app, HCP did not work even with the fix.

But when we tried to uninstall the app and did a fresh install of the iOS with the app, HCP worked.

(...testing android)

rj-david on 14 Jan 2019

HCP is not working in Android with Meteor 1.8.1-beta.13 (tested on multiple android phones)

We are using the Reload.isWaitingForResume() feature and it can detect that a new version is available. But once we did a refresh, the new version is not being successfully loaded.

rj-david on 14 Jan 2019

@rj-david

If I understand https://github.com/meteor/cordova-plugin-meteor-webapp/pull/62 correctly, https://github.com/meteor/meteor/pull/10219 needs to merged to stay backward compatible.

Do you have any logs, hard to help without them?

menelike on 14 Jan 2019

@rj-david
HCP won’t remove files from an app’s assets, it only downloads new ones and updates files that have changed, but no deletes. Any chance this is why you have to do an uninstall to get to your proper updated app version? Just a guess. Do you get any errors in the console when it doesn’t work without a reinstall?

RealHandy on 14 Jan 2019

Unfortunately we were testing with production builds (through apple test flight and android release channels). So the apps were not set on debug mode. We will test 1.8.1-beta.14 today and if it won't be successful, we will build for debugging.

rj-david on 15 Jan 2019

I can confirm now that HCP works for both android and iOS using Meteor 1.8.1-beta.14

rj-david on 15 Jan 2019

👍3 🎉1

@rj-david That’s great!

RealHandy on 15 Jan 2019

Is this related to any of the changes for beta.14?
https://github.com/meteor/meteor/issues/10426

rj-david on 19 Jan 2019

The HCP fix itself wouldn’t be related, it doesn’t do anything with those configs.

RealHandy on 19 Jan 2019

We noticed recently that during development using an actual device, HCP is not updating the build in the actual device.

We are using Reload.isWaitingForResume() and when this changes, we trigger HCP with window.location.replace(window.location.href)

We will debug why this is happening but does any of you have any idea on what to check?

rj-david on 28 Jan 2019

@RealHandy, @benjamn

We are actively developing an app in beta and launched last Monday using Meteor 1.8.1-beta.17. We found an issue with HCP in iOS with the latest fix. The first HCP in iOS worked without problem every time. After that the HCP stopped working again.

rj-david on 14 Feb 2019

@rj-david Are you able to provide some logs from the affected devices?

menelike on 14 Feb 2019

@rj-david Are you able to provide some logs from the affected devices?

We don't have any. What is the best way to get these logs?

rj-david on 14 Feb 2019

@rj-david You connect your iPhone to your Mac with a usb, then you run Xcode and from the top menu select Window - > Devices , then select your connected device from left side list. The current log will show scrolling at the bottom of the screen, though you may need to hit the little arrow at the bottom to expand logs. Then you reproduce the problem and it will show in the logs. A lot of other apps and system stuff may be filling the logs, so you’re likely to need to filter the log by something specific to your app (or just have good eyes).

On Feb 14, 2019, at 3:55 AM, rj-david notifications@github.com wrote:

@rj-david Are you able to provide some logs from the affected devices?

We don't have any. What is the best way to get these logs?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

RealHandy on 14 Feb 2019

@RealHandy, I'm not 100% sure if we can replicate this for a development setup. Our team has been developing with an iPhone connected for quite some time and nobody raised an issue (I was using Ubuntu + Android though). We just noticed the problem when we started releasing in production. In all versions, the iOS app will HCP once when a new version is deployed. For the next version, it won't.

I'll check with those in our team using iphone and mac tomorrow.

Anybody knows if APM can catch this and what should we look at in the apm logs?

rj-david on 14 Feb 2019

This is the only relevant logs that we can see as related (i.e. the BLACKLIST part)

2019-02-18 12:54:32.961450+0800 Bountee[15907:7331347] App startup confirmed
2019-02-18 12:54:41.794419+0800 Bountee[15907:7331347] Start downloading asset manifest from: manifest.json -- http://192.168.1.18:3003/__cordova/
2019-02-18 12:54:41.848020+0800 Bountee[15907:7332764] Downloaded asset manifest for version: 38a4c717e7e8c577e9eac4a97566cd3c0013001b
2019-02-18 12:54:41.848491+0800 Bountee[15907:7332764] BLACKLIST - blacklistedVersions: []
2019-02-18 12:54:41.848580+0800 Bountee[15907:7332764] Finished downloading new asset bundle version: 38a4c717e7e8c577e9eac4a97566cd3c0013001b
2019-02-18 12:54:41.883098+0800 Bountee[15907:7331347] Serving asset bundle version: 38a4c717e7e8c577e9eac4a97566cd3c0013001b
2019-02-18 12:54:42.886473+0800 Bountee[15907:7331347] App startup confirmed
2019-02-18 12:54:42.921297+0800 Bountee[15907:7331347] Start downloading asset manifest from: manifest.json -- http://192.168.1.18:3003/__cordova/
2019-02-18 12:54:42.979222+0800 Bountee[15907:7332978] Downloaded asset manifest for version: 38a4c717e7e8c577e9eac4a97566cd3c0013001b

rj-david on 21 Feb 2019

This shows you’re successfully getting the asset manifest and the app is resetting due to having gotten it. Then it gets the asset manifest in the restarted version. All of that looks as it should be and there are no errors due to asset update. I don’t know what the blacklist means, it has no versions in its list, and the app is proceeding to restart and function after that. There’s no error here that I can see, unless it’s related in some way to the blacklist. This log has no issue related to the original #10277 bug. Bummer, not much to go on here.

On Feb 20, 2019, at 9:55 PM, rj-david notifications@github.com wrote:

This is the only relevant logs that we can see as related (i.e. the BLACKLIST part)

2019-02-18 12:54:32.961450+0800 Bountee[15907:7331347] App startup confirmed
2019-02-18 12:54:41.794419+0800 Bountee[15907:7331347] Start downloading asset manifest from: manifest.json -- http://192.168.1.18:3003/__cordova/
2019-02-18 12:54:41.848020+0800 Bountee[15907:7332764] Downloaded asset manifest for version: 38a4c717e7e8c577e9eac4a97566cd3c0013001b
2019-02-18 12:54:41.848491+0800 Bountee[15907:7332764] BLACKLIST - blacklistedVersions: []
2019-02-18 12:54:41.848580+0800 Bountee[15907:7332764] Finished downloading new asset bundle version: 38a4c717e7e8c577e9eac4a97566cd3c0013001b
2019-02-18 12:54:41.883098+0800 Bountee[15907:7331347] Serving asset bundle version: 38a4c717e7e8c577e9eac4a97566cd3c0013001b
2019-02-18 12:54:42.886473+0800 Bountee[15907:7331347] App startup confirmed
2019-02-18 12:54:42.921297+0800 Bountee[15907:7331347] Start downloading asset manifest from: manifest.json -- http://192.168.1.18:3003/__cordova/
2019-02-18 12:54:42.979222+0800 Bountee[15907:7332978] Downloaded asset manifest for version: 38a4c717e7e8c577e9eac4a97566cd3c0013001b
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

RealHandy on 21 Feb 2019

@rj-david you mentioned in the 1.8.1 release thread that the second HCP on iOS fails consistently.

Do others experience the same thing?

@wojtkowiak maybe you could chime in?

KoenLav on 4 Mar 2019

@KoenLav, yes, we were able to confirm it multiple times in our project.

Just a few minutes ago, we released a new version without the mdg:reload-on-resume package to test if that was the one causing the issue. Unfortunately with iOS, we have an earlier release with a change in mobile-config.js which meant we have to go through the App Store review. We expect it to be approved within 12 hours from this post. Will post here if we find something useful.

rj-david on 4 Mar 2019

@rj-david you mentioned in the 1.8.1 release thread that the second HCP on iOS fails consistently.

Do others experience the same thing?

@wojtkowiak maybe you could chime in?

I am definitely experiencing it. I've been unable to deploy iOS for more than a month. Works fine locally, but not in App Store. Could not find good logs.

mozfet on 4 Mar 2019

I am definitely experiencing it. I've been unable to deploy iOS for more than a month. Works fine locally, but not in App Store. Could not find good logs.

@mozfet, are you using at least 1.8.1-beta.14 ?

rj-david on 4 Mar 2019

I am definitely experiencing it. I've been unable to deploy iOS for more than a month. Works fine locally, but not in App Store. Could not find good logs.

@mozfet, are you using at least 1.8.1-beta.14 ?

Yup - [email protected]

mozfet on 4 Mar 2019

👍1

I am using [email protected] and been pushing new builds to my HockeyApp Test environment. The hot push fails the first time and all subsequent times - on IOS and Android.

buymybm100 on 4 Mar 2019

@buymybm100, how did you deploy your ipa and apk builds? Testflight? Beta channels in play store console?

rj-david on 4 Mar 2019

I’m on my fork of the plugin and 1.8, and HCP works fine for any number of HCP updates. When I get a chance, I’ll debug 1.8.1 and see if I can see anything. It’s worth mentioning that I had to patch a 3rd party plugin because the “restart” of HCP caused a crashing bug, so other plugins could be an issue for HCP.

RealHandy on 4 Mar 2019

@RealHandy, what 3rd party plugin did you need to patch? Might give a clue on this

rj-david on 4 Mar 2019

Heh, indooratlas — def not something anyone else is using.

On Mar 4, 2019, at 9:54 AM, rj-david notifications@github.com wrote:

@RealHandy, what 3rd party plugin did you need to patch? Might give a clue on this

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

RealHandy on 4 Mar 2019

@buymybm100, how did you deploy your ipa and apk builds? Testflight? Beta channels in play store console?

Through Hockeyapp as it can host apps for both IOS and Android.

buymybm100 on 5 Mar 2019

Hi All,

Are you connecting to your devices and examining the console output? There are a number of legitimate reasons why HCP will fail:

if there is an issue on startup that causes any Meteor.startup handler to fail or run too slowly then the build will be marked as an error build and Meteor won't try to download it again. The console will show this case.
Meteor detects that the cordova packages are different for the HCP than the installed app and refuses to load the HCP. The console will show this case.
Builds of cordova-plugin-meteor-webapp prior to 1.6.5 had an issue with partial downloads which was fixed with PR 38 which is the default for v1.8.1. The console shows the app has failed at a really weird place, upon inspection you can see that app.js is incomplete.

brucejo75 on 5 Mar 2019

@Nauzer, I am replying here instead from the release PR thread.

Reference from other folks here. @Nauzer did a test showing that there was nothing wrong with the HCP in production. Here is the link: https://github.com/meteor/meteor/pull/10248#issuecomment-469680616

For the question regarding my plugins, here they are:

[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]

rj-david on 6 Mar 2019

Are you connecting to your devices and examining the console output?

@brucejo75, we cannot replicate it in development. Happening for us in production. What is the best way to get any logs out from production?

rj-david on 6 Mar 2019

👍1

@buymybm100, how did you deploy your ipa and apk builds? Testflight? Beta channels in play store console?

Through Hockeyapp as it can host apps for both IOS and Android.

It breaks for me when loading it with Testflight using my STAGE environment. It does not happen in Dev, and I can use the Browser as normally; so there should be no build or dependency issues.

mozfet on 6 Mar 2019

I can also load the App directly onto my Dev Android and iOS devices and it works fine, so I do not expect any Cordova issues either... not that I can see any of this in PROD, since debug logs are not available and it does not proceed past the Splash Screen.

Is it possible to connect a debugger to an iOS App deployed using Testflight?

mozfet on 6 Mar 2019

Happening for us in production. What is the best way to get any logs out from production?

@rj-david @mozfet You can build your project as a developer build (instead of distribution for app store), you'll be able to install that on your device directly and see the console log.

In Xcode go to Window ⇾ Organizer, then you can select your archived build, click on export and you should see

After that, go to Window ⇾ Devices with your iPhone attached, you should be able to drag and drop that build on your device.

Beside of that, you can always just run the production build locally if you just push the "play icon"? I really don't understand the trouble, the HCP should fail then as well, but you can debug everything as you like.

menelike on 6 Mar 2019

It does not happen in DEV when you load it directly on the device using XCode, so there is nothing to log. With me it only happens when loading in STAGE (Testflight - Appstore) - and assumably also PROD (Deploy on Appstore).

mozfet on 6 Mar 2019

@rj-david @mozfet You can build your project as a developer build (instead of distribution for app store), you'll be able to install that on your device directly and see the console log.

We are doing this now. I'll post here the results once we are done

rj-david on 6 Mar 2019

👍1

@wildhart was able to replicate our experience: https://github.com/meteor/meteor/pull/10248#issuecomment-470054560

The plugins that were the same for our builds are as follows:
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]

rj-david on 6 Mar 2019

@mozfet

What exactly do you mean with DEV? The local meteor development (aka http://localhost:3000) or a dev build targeting your production instance?

menelike on 6 Mar 2019

Hi @rj-david @mozfet @wildhart

Try adding the latest version of cordova-plugin-meteor-webapp to your cordova plugins list.
[email protected]

I think underwater Meteor is still using 1.6.0 and I manually set it to a higher version in my Cordova plugins file. If that is the case we might need to do a PR for 1.8.1 release to update cordova-plugin-meteor-webapp to it's latest version.

Nauzer on 6 Mar 2019

Looks like @wildhart has already done this...
As I can confirm I do not experience this issue I post hereby my cordova-plugins & package versions:

https://pastebin.com/Lz3MnnpB

Just to make sure I've just done a 'Release' build in Xcode as well. And I can't reproduce the behaviour described by @rj-david and @wildhart. Unless you can only reproduce this behaviour with a compiled app installed via App Store? Or can you reproduce by making a build and running it from Xcode against an actual server as well?

screen shot 2019-03-06 at 13 00 50

Nauzer on 6 Mar 2019

@menelike

DEV as in development environment using local machines and Xcode and Android Studio and running in Similators and Sideloading on Devices.
STAGE aka TEST and PRE_PROD environment, where we use test channels representing the real world, and a temp domain name.
PROD as in production environment, using official .com domain, App Store and Play Store Distribution.

mozfet on 6 Mar 2019

@mozfet This is what I was trying to explain, you can run a dev build (development in terms of Xcode) against your production. The app should logically behave the same, except of debugging features.
Or in simple terms, the app will be the same as the one from the app store, just with debugging features enabled.

menelike on 6 Mar 2019

@menelike I have run dev build and sideloaded it to talk with our STAGE server, which is the same as PROD server will become (but on a different domain). It works fine, no issues. Only once it is loaded using Test Flight to also talking with our STAGE server, I have app level logs, but they are not shown and the app does not progress beyond the splash screen - thus no logs...

mozfet on 6 Mar 2019

Ok, we got something. Hopefully this is related

2019-03-06 20:46:08.897897+0800 Bountee[1257:324345] ERROR: checkForUpdates requires a rootURL to be configured
2019-03-06 20:46:10.660483+0800 Bountee[1257:324345] App startup confirmed
2019-03-06 20:46:10.747099+0800 Bountee[1257:324345] ERROR: checkForUpdates requires a rootURL to be configured

[Addendum]
Restarting the app, we got this

2019-03-06 20:57:27.756085+0800 Bountee[1272:331622] Download failure: Non-success status code 404 for asset: /__cordova/082522452f0ed7b03ab15cb4f71b3f33369e7c6e.stats.json
2019-03-06 20:57:27.759005+0800 Bountee[1272:331621] Task <8D6253F3-14BA-4AD3-B56C-BBC0AC42060E>.<1> load failed with error Error Domain=NSURLErrorDomain Code=-999 "cancelled" UserInfo={NSErrorFailingURLStringKey=https://app.bountee.com/__cordova/__cordova/082522452f0ed7b03ab15cb4f71b3f33369e7c6e.stats.json?meteor_dont_serve_index=true, NSErrorFailingURLKey=https://app.bountee.com/__cordova/__cordova/082522452f0ed7b03ab15cb4f71b3f33369e7c6e.stats.json?meteor_dont_serve_index=true, _NSURLErrorRelatedURLSessionTaskErrorKey=(
    "LocalDataTask <8D6253F3-14BA-4AD3-B56C-BBC0AC42060E>.<1>"
), _NSURLErrorFailingURLSessionTaskErrorKey=LocalDataTask <8D6253F3-14BA-4AD3-B56C-BBC0AC42060E>.<1>, NSLocalizedDescription=cancelled} [-999]
2019-03-06 20:57:27.759392+0800 Bountee[1272:331622] Task <E17562CD-4E33-4C14-A911-9352DFACCB27>.<2> finished with error - code: -999
2019-03-06 20:57:27.763586+0800 Bountee[1272:331589] ERROR: {"line":51,"column":30,"sourceURL":"http://localhost:12224/plugins/cordova-plugin-meteor-webapp/www/webapp_local_server.js"}

rj-david on 6 Mar 2019

@rj-david This seems to be a configuration issue. Have you built your project from meteor just like you would for production?

menelike on 6 Mar 2019

in your Settings file do you have a ROOT_URL key?
Can you share your Settings file?
Did you change anything in that between the two updates?

{
"public": { ... },
"private": {
"ROOT_URL": "https://YOURDOMAIN"
}
}

Nauzer on 6 Mar 2019

@rj-david This seems to be a configuration issue. Have you built your project from meteor just like you would for production?

Yes. The app was running ok and HCP'd initially for the first server update. On the 2nd server update, the errors starting to occur right after the new build became live in production server

rj-david on 6 Mar 2019

https://app.bountee.com/__cordova/__cordova/082522452f0ed7b03ab15cb4f71b3f33369e7c6e.stats.json?meteor_dont_serve_index=true

Just by looking at this, why does it include __cordova/__cordova (2x times)?
We need to check if the URLs are generated correctly.

Update

I can confirm that the URL scheme https://foo.bar/__cordova/HASH.stats.json should resolve.

@rj-david Right now I am receiving

curl https://app.bountee.com/__cordova/082522452f0ed7b03ab15cb4f71b3f33369e7c6e.stats.json                                                                                                                              
<!DOCTYPE html>
<html>
<head>
  <meta charset="utf-8">
  <meta name="format-detection" content="telephone=no">
  <meta name="viewport" content="user-scalable=no, initial-scale=1, maximum-scale=1, minimum-scale=1, width=device-width, height=device-height, viewport-fit=cover">
  <meta name="msapplication-tap-highlight" content="no">
  <meta http-equiv="Content-Security-Policy" content="default-src * gap: data: blob: 'unsafe-inline' 'unsafe-eval' ws: wss:;">
  <link rel="stylesheet" type="text/css" class="__meteor-css__" href="/__cordova/5370ba3e95f7d290116ed9449858259228912103.css?meteor_css_resource=true">
<meta charset="utf-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0, shrink-to-fit=no, user-scalable=no, maximum-scale=1.0, minimum-scale=1.0"
    />
    <meta name="google-site-verification" content="l1FS5KrERDmMfa-o1wMRbiZpOQCs-sUXDXwbjWVk_RE" />
    <title>Bountee: Loyalty for Everybody</title>
  <script type="text/javascript">
    __meteor_runtime_config__ = JSON.parse(decodeURIComponent("%7B%22meteorRelease%22%3A%22METEOR%401.8.1-beta.20%22%2C%22gitCommitHash%22%3A%224761546adee4d0db1c6ecbc73245b9fdc2a80278%22%2C%22meteorEnv%22%3A%7B%22NODE_ENV%22%3A%22production%22%2C%22TEST_METADATA%22%3A%22%7B%7D%22%7D%2C%22PUBLIC_SETTINGS%22%3A%7B%22appAbsoluteURL%22%3A%22https%3A%2F%2Fapp.bountee.com%22%2C%22appName%22%3A%22Bountee%22%2C%22oneSignalAppId%22%3A%22649be042-1ffa-43f2-8601-059f6352bba5%22%2C%22securityTokenExpiry%22%3A1209600%2C%22cdnPrefixUrl%22%3A%22https%3A%2F%2Fapp-assets.bountee.com%22%2C%22simulatedNetworkDelay%22%3A0%7D%2C%22ROOT_URL%22%3A%22https%3A%2F%2Fapp.bountee.com%2F%22%2C%22ROOT_URL_PATH_PREFIX%22%3A%22%22%2C%22autoupdate%22%3A%7B%22versions%22%3A%7B%22web.browser%22%3A%7B%22version%22%3A%22654770106e85e5d41946b823f174b045bf626dcb%22%2C%22versionRefreshable%22%3A%224410118943a557c4c5a097860882622ddbd4d3f6%22%2C%22versionNonRefreshable%22%3A%228987973e4a82e37e64d00d3a90523a81c23cfacf%22%7D%2C%22web.browser.legacy%22%3A%7B%22version%22%3A%22fd07996d6a79b4cf496e6bccdfa3b1aeb5e22e0a%22%2C%22versionRefreshable%22%3A%224410118943a557c4c5a097860882622ddbd4d3f6%22%2C%22versionNonRefreshable%22%3A%22924f1e07cf178329e908d43078d246aee6b781c3%22%7D%2C%22web.cordova%22%3A%7B%22version%22%3A%22e43010d246a6f954088b175bf0a9fa428c4de181%22%2C%22versionRefreshable%22%3A%224410118943a557c4c5a097860882622ddbd4d3f6%22%2C%22versionNonRefreshable%22%3A%22e0979381e30d28915bd587f94df70c3cd2979c49%22%7D%7D%2C%22autoupdateVersion%22%3Anull%2C%22autoupdateVersionRefreshable%22%3Anull%2C%22autoupdateVersionCordova%22%3Anull%2C%22appId%22%3A%22vhrjce574bkd.favlbbaeqzut%22%7D%2C%22appId%22%3A%22vhrjce574bkd.favlbbaeqzut%22%2C%22accountsConfigCalled%22%3Atrue%2C%22DDP_DEFAULT_CONNECTION_URL%22%3A%22https%3A%2F%2Fapp.bountee.com%2F%22%7D"));
    if (/Android/i.test(navigator.userAgent)) {
      if (!__meteor_runtime_config__.httpProxyPort) {
        __meteor_runtime_config__.ROOT_URL = (__meteor_runtime_config__.ROOT_URL || '').replace(/localhost/i, '10.0.2.2');
        __meteor_runtime_config__.DDP_DEFAULT_CONNECTION_URL = (__meteor_runtime_config__.DDP_DEFAULT_CONNECTION_URL || '').replace(/localhost/i, '10.0.2.2');
      }
    }
  </script>

  <script type="text/javascript" src="/cordova.js"></script>
  <script type="text/javascript" src="/__cordova/770229e9f890607115d0f9295b325e97c3bf52d5.js?meteor_js_resource=true"></script>

</head>

<body><div id="react-container"></div></body>
</html>

I have no idea why this is the result, usually a json should be responded. Maybe your logs were just not uptodate anymore because a new bundle has been deployed in mean time.

menelike on 6 Mar 2019

in your Settings file do you have a ROOT_URL key?
Can you share your Settings file?
Did you change anything in that between the two updates?

{
"public": { ... },
"private": {
"ROOT_URL": "https://YOURDOMAIN"
}
}

We don't. We have the ROOT_URL in the server i.e. bountee.service file

Could this be the cause of our issue?

rj-david on 6 Mar 2019

I have no idea why this is the result, usually a json should be responded.

https://app.bountee.com/__cordova/manifest.json outputs https://app.bountee.com/__cordova/9a5292ccde3010222a53a8be41aeb0ad65a60e1f.stats.json?meteor_js_resource=true which doesn't respond with a JSON as well.

Hope this can lead us somewhere.

(My team just went home - past 9pm now locally; if there will be anything required from us, we will work on it tomorrow as soon as we are back in the office)

rj-david on 6 Mar 2019

@rj-david

How do you build your app? We use meteor build outputDir --server=https://prod.server --mobile-settings settings.json. AFAIK ROOT_URL should not be affecting production app builds at all, hence I don't understand your logs. Maybe a meteor reset might be run before you build, I've seen traces of development stuff when bundling for production in the past.

Maybe your server is not configured correctly, and upon the first HCP your clients receive a faulty response, hence HCP doesn't work anymore. I also see, that you use appAbsoluteURL:"https://app.bountee.com" in your settings, this line raises questions, since it should not be needed if Meteor is properly configured. Maybe I am missing something....

menelike on 6 Mar 2019

@menelike

We build similar to what you posted. Normally, it is being built using our CI box but for this test, I built it manually. Tomorrow, I'll delete the local folder and build again

Any idea on what to check on our server setup? Note that we don't have a problem with Android.

The settings values are all being used in the app. The server settings are being downloaded separately from a different location which is automatically downloaded by our ASG in AWS when scaling or deploying (as part of our CI/CD pipeline)

rj-david on 6 Mar 2019

@rj-david
You've got a good point with: _Note that we don't have a problem with Android._

As this point this has become a guessing game, still I'd try to understand the URLs first, even if this is not the causing the issue (__cordova/__cordova is just too suspicious).

menelike on 6 Mar 2019

I'm building/deploying with MUP. HCP works for me every time with Android, but on iOS only works the first time after a fresh app install from the App Store. I can't try loading a DEV build onto a device because I don't currently have access to a mac, so I can't get the logs, sorry.

ROOT_URL is set within MUP: ROOT_URL: 'https://www.virtualinout.com'

Here's my manifest if that helps: https://www.virtualinout.com/__cordova/manifest.json

I'm already using [email protected]: https://pastebin.com/yYvNG9sK

Edit: This happens even with the most minor of html/js changes, with no plugin updates or anything significant.

wildhart on 6 Mar 2019

@RealHandy, you might be more familiar with this:

https://github.com/meteor/meteor/issues/10277#issuecomment-470095469

rj-david on 7 Mar 2019

I'm on a mobile phone and difficult to check further but here is the start:

private void checkForUpdates(final CallbackContext callbackContext) {
        cordova.getThreadPool().execute(new Runnable() {
            public void run() {
                HttpUrl rootUrl = HttpUrl.parse(currentAssetBundle.getRootUrlString());
                if (rootUrl == null) {
                    callbackContext.error("checkForUpdates requires a rootURL to be configured");
                    return;
                }
                HttpUrl baseUrl = rootUrl.resolve("__cordova/");
                assetBundleManager.checkForUpdates(baseUrl);
                callbackContext.success();
            }
        });
    }

https://github.com/meteor/cordova-plugin-meteor-webapp/blob/master/src/android/WebAppLocalServer.java

[Erratum]
Here is the ios version

open func checkForUpdates(_ command: CDVInvokedUrlCommand) {
    guard let rootURL = configuration.rootURL else {
      let errorMessage = "checkForUpdates requires a rootURL to be configured"
      let result = CDVPluginResult(status: CDVCommandStatus_ERROR, messageAs: errorMessage)
      commandDelegate?.send(result, callbackId: command.callbackId)
      return
    }

    let baseURL = rootURL.appendingPathComponent("__cordova/")
    assetBundleManager.checkForUpdatesWithBaseURL(baseURL)

    let result = CDVPluginResult(status: CDVCommandStatus_OK)
    commandDelegate?.send(result, callbackId: command.callbackId)
  }

https://github.com/meteor/cordova-plugin-meteor-webapp/blob/master/src/ios/WebAppLocalServer.swift

rj-david on 7 Mar 2019

How/Where do you guys set your ROOT_URL?

@Nauzer?

[Addendum]
Ok please disregard this request. I just checked our manifest and saw that the ROOT_URL is successfully reflected in the meteor runtime config variable

"meteorRuntimeConfig":"{"meteorRelease":"[email protected]",
"gitCommitHash":"4761546adee4d0db1c6ecbc73245b9fdc2a80278",
"meteorEnv":{  
   "NODE_ENV":"production",
   "TEST_METADATA":"{}"
},
"PUBLIC_SETTINGS":{  
   "appAbsoluteURL":"https://app.bountee.com",
   "appName":"Bountee",
   "oneSignalAppId":"649be042-1ffa-43f2-8601-059f6352bba5",
   "securityTokenExpiry":1209600,
   "cdnPrefixUrl":"https://app-assets.bountee.com",
   "simulatedNetworkDelay":0
},
"ROOT_URL":"https://app.bountee.com/",
"ROOT_URL_PATH_PREFIX":"",
"autoupdate":{  
   "versions":{  
      "web.browser":{  
         "version":"654770106e85e5d41946b823f174b045bf626dcb",
         "versionRefreshable":"4410118943a557c4c5a097860882622ddbd4d3f6",
         "versionNonRefreshable":"8987973e4a82e37e64d00d3a90523a81c23cfacf"
      },
      "web.browser.legacy":{  
         "version":"fd07996d6a79b4cf496e6bccdfa3b1aeb5e22e0a",
         "versionRefreshable":"4410118943a557c4c5a097860882622ddbd4d3f6",
         "versionNonRefreshable":"924f1e07cf178329e908d43078d246aee6b781c3"
      },
      "web.cordova":{  
         "version":"e43010d246a6f954088b175bf0a9fa428c4de181",
         "versionRefreshable":"4410118943a557c4c5a097860882622ddbd4d3f6",
         "versionNonRefreshable":"e0979381e30d28915bd587f94df70c3cd2979c49"
      }
   },
   "autoupdateVersion":null,
   "autoupdateVersionRefreshable":null,
   "autoupdateVersionCordova":null,
   "appId":"vhrjce574bkd.favlbbaeqzut"
},
"appId":"vhrjce574bkd.favlbbaeqzut",
"accountsConfigCalled":true,
"DDP_DEFAULT_CONNECTION_URL":"https://app.bountee.com/"
}"

rj-david on 7 Mar 2019

https://app.bountee.com/__cordova/__cordova/082522452f0ed7b03ab15cb4f71b3f33369e7c6e.stats.json?meteor_dont_serve_index=true

Just by looking at this, why does it include __cordova/__cordova (2x times)?
We need to check if the URLs are generated correctly.

Update

I can confirm that the URL scheme https://foo.bar/__cordova/HASH.stats.json should resolve.

The URL of the file should have been:
https://app.bountee.com/__cordova/770229e9f890607115d0f9295b325e97c3bf52d5.stats.json?meteor_js_resource=true

So (1) wrong url path (2x cordova folder), and (2) wrong hash

(Note that the hash might change moving forward as the team will start deploying as we work today. But at the time of posting, the URL I posted works)

rj-david on 7 Mar 2019

Made a 2nd test today for iOS HCP. Once again, the first HCP worked, the 2nd HCP did not. But this time, there aren't any error messages. The only relevant log messages were

2019-03-07 14:53:43.255402+0800 Bountee[1364:373200] Start downloading asset manifest from: manifest.json -- https://app.bountee.com/__cordova/
2019-03-07 14:53:43.262244+0800 Bountee[1364:376514] Downloaded asset manifest for version: 95d7e443cacd42bd85f32552c44af2f88520bdae

rj-david on 7 Mar 2019

👍1

@rj-david I use a settings-production.json with Galaxy settings to deploy to Galaxy and do not set a ROOT_URL... should I?

mozfet on 7 Mar 2019

@mozfet Could you try that?
I do have this setting - make sure you include the setting (private.ROOT_URL) in your initial app build and on your galaxy server build using the following steps.
I always add the first 3 lines as I've seen old settings files "sticking around" when not doing this.

rm -rf .meteor/local/cordova-build
meteor remove-platform ios
meteor add-platform ios
meteor build ... --mobile-settings=yoursettingspath.js // mind the =
meteor deploy ... --settings yoursettingspath.js // no =

Nauzer on 7 Mar 2019

@Nauzer

Ok, do you mean I should make my settings-productions.json file should look like this?

{
  "galaxy.meteor.com": {
    "env": {
      "MONGO_URL": "...",
      "MONGO_OPLOG_URL": "...",
      "MAIL_URL": "...",
      "ROOT_URL": "https://www.mydomain.com",
    }
  }
}

I have an existing mobile-config.js in the root of my project folder, which used to work fine as default I do not expect I need to change that, and I then usually build with...

$ meteor build <BUILD_DIR> --server <SERVER_URL>

mozfet on 7 Mar 2019

Nope - It should be part of your 'private' element I think.

{
  "public": {
    "param1": "abc"
  },
  "private": {
    "ROOT_URL": "https://yourdomain or local IP"
  },
  "galaxy.meteor.com": {
    "env": {
       "MONGO_URL": "...",
       "MONGO_OPLOG_URL": "...",
     }
  }
}

Please note that mobile-config.js is something different than the loaded settings file. Mobile config is picked up automatically. Settings file you need to explicitly add with above mentioned flags.

Besides I build with:

meteor build {outputDir} --server={https://domain.com}:443 --mobile-settings={pathToSettingsFile.js}

Explicitly adding :443 and with the = sign somehow was proven to be necessary somewhere in the past can't remember why exactly but it might be of help now.

Nauzer on 7 Mar 2019

@rj-david Yep, WebAppLocalServer.swift is in the code I debugged to resolve the prior iOS HCP bug. The double __cordova in the failed path seems like a clear culprit in that log, although I almost feel like I’ve seen that before. I haven’t gone to 1.8.1 beta, so I don’t know whether I’d be able to repro this new issue or not.

RealHandy on 7 Mar 2019

Just a thought, but could this line in src/ios/AssetBundleManager.swift:

211  // Workaround for https://github.com/meteor/cordova-plugin-meteor-webapp/issues/56
212 if assetBundle.assetExistsInBundle("/__cordova" + asset.urlPath) { continue }

Somehow be causing the downloading of the new bundle to be skipped?

wildhart on 7 Mar 2019

@Nauser Thank you. That seems to have fixed it for me. I will continue testing.

mozfet on 11 Mar 2019

@wildhart that would only skip a new asset if that asset does NOT occur twice in manifest.json — once with the __cordova in the path and once without — and that would be a new manifest behavior. It could explain the double __cordova if asset.urlPath has a __cordova in it already, but I think that would mean the assets have an __cordova created by the dev in the public assets dir. I should have time this week to look in on this issue.

RealHandy on 11 Mar 2019

@mozfet np. Looking forward to hear your results of HCP against your prod(-like) environment.

Nauzer on 12 Mar 2019

@Nauzer, adding ROOT_URL in my private settings does not work in my case.

Regarding the manifest, I was able to do some further debugging now. I observed that the first time the HCP happens, seem like the iOS app caches manifest.json. The next time a new version of the app exists in the server, the version of the manifest being displayed in the console was still the old version.

First HCP success console message:
Downloaded asset manifest for version: ABC

Second HCP failed console message:
Downloaded asset manifest for version: ABC <--- same version being displayed from the first HCP

If I uninstalled the app and reinstalled it, then the console will display a new version and the HCP will be successful:
Downloaded asset manifest for version: XYZ

rj-david on 12 Mar 2019

👍1

Made two more tests and got the same result as above. The 2nd HCP seemed to be caching the manifest downloaded and the version did not change.

rj-david on 12 Mar 2019

@rj-david sorry to hear. Just a question; is that with a settings.js file you pass as a build parameter in both the Cordova as the deployed build (e.g. a file part of your bundle - see a few posts back for my used commands & tips) or with this remote API file you referred to earlier?

If the latter, using a settings file as per the Meteor docs might be worth your while.

Nauzer on 12 Mar 2019

I am still working with v1.7.0.5 of Meteor. I have observed that the first download to a freshly installed Android App, does not complete. And this is reproducible in my dev environment.

Repro steps

In Development environment

device: Uninstall app.
device: Install app.
device: Start app.
Dev server: update the app for an HCP.

Result: HCP will happen (Reload._onMigrate fires), but the app running is not updated to the latest version. It is still running the version that the app was built with.

Observation

At this point, connect to the APP for debugging and from the console call location.reload().

Result: the update will complete and my version is now the latest.

Somehow the first HCP update is not completed properly.
After the first HCP, subsequent HCPs work fine.
I think this may have been happening for a while, but I just would bang on location.reload() as part of my dev process.

Workaround

I have not tried (busy on other stuff) this but a way to encode this workaround would be:

let needsToReload = localStorage.getItem('needsToReload');
Reload._onMigrate((retry) => {
  if(!needsToReload) localStorage.setItem(`needsToReload`, 'true');
});

if(needsToReload && needsToReload === 'true') {
  localStorage.setItem('needsToReload', 'false');
  location.reload();
}

This should only fire a location.reload() on the first HCP.
Note: this code needs to be on the installed APP.

brucejo75 on 12 Mar 2019

@rj-david
Some years back we had issues with HCP in conjunction with our web server (nginx). Do you have a web server in between? It might interfere with meteor when caching is enabled.

menelike on 12 Mar 2019

@Nauzer, yes, through a settings.json file

@menelike, good point. We are using nginx. I'll ask our devops to exclude manifest.json from the cache and test again tomorrow.

rj-david on 12 Mar 2019

@rj-david Just found the old thread: https://forums.meteor.com/t/app-constantly-refreshing-after-an-update/23586/113 might be outdated though.

menelike on 12 Mar 2019

👍1

@brucejo75, before 1.8.1-beta, we did try variations of reloading/restarting the app but it only worked with Android. Beta.15 solved all issues we had with android so we removed the reload code since it wasn't working with iOS

rj-david on 12 Mar 2019

👍1

@menelike, I'm sure we have that cache since I was the one who initially set it. Will get back tomorrow for the results. Thanks

rj-david on 12 Mar 2019

We're also using nginx, deployed with MUP. Haven't changed any ngnix settings from the MUP defaults.
Response headers on https://www.virtualinout.com/__cordova/manifest.json show cache-control: public, max-age=31536000 but that should be served the same for Android and iOS.

wildhart on 12 Mar 2019

@mozfet np. Looking forward to hear your results of HCP against your prod(-like) environment.

Looks like its working fine in my STAGE environment. Hold thumbs... going to try PROD as soon as Apple approved the app in the App Store.

mozfet on 13 Mar 2019

@menelike, removing the cache settings in our nginx solved this problem for us.

@Nauzer, @RealHandy, @benjamn, FYI.

Thanks everyone and cheers!

rj-david on 13 Mar 2019

🎉1

@rj-david puhh....finally, this was a hard one. Now everyone can be sure that HCP works again.

menelike on 13 Mar 2019

👍1

So what would I need to change in my default MUP nginx config to fix my experience of this same issue?

MUP provides the nginxServerConfig setting but I wouldn't know what to change. @zodern, have you heard of other MUP users having this issue (HCP on iOS only working the 1st time after a fresh app install. Android is fine. Previously experienced by @rj-david and myself above, but resolved for @rj-david by removing nginx config settings)?

wildhart on 13 Mar 2019

@wildhart, I took a quick look at MUP and seems like it has a default nginx setting. Since this is being used by a lot of meteor users, the understanding is that it has the correct nginx cache settings (or in this case, there are no cache settings).

Have you seen anything related to what we saw yesterday: https://github.com/meteor/meteor/issues/10277#issuecomment-471980580

rj-david on 13 Mar 2019

We're also using nginx, deployed with MUP. Haven't changed any ngnix settings from the MUP defaults.
Response headers on https://www.virtualinout.com/__cordova/manifest.json show cache-control: public, max-age=31536000 but that should be served the same for Android and iOS.

Sorry, I missed this post. This cache setting was the one that was previously causing us problems

rj-david on 13 Mar 2019

I discovered the MUP command mup proxy nginx-config which gave this output: https://pastebin.com/bUcbC0Pz

I can't see anything there about cache except for SSL cache.

Have you seen anything related to what we saw yesterday: #10277 (comment)

I haven't been able to access iOS app logs during an HCP yet, but I'll try.

wildhart on 13 Mar 2019

You might want to explicitly add a location block just for manifest with cache control header ignored:
https://www.nginx.com/blog/nginx-caching-guide/

I'm not familiar how to use nginxServerConfig

rj-david on 14 Mar 2019

Workaround

I have not tried (busy on other stuff) this but a way to encode this workaround would be:
codeblock
This should only fire a location.reload() on the first HCP.
Note: this code needs to be on the installed APP.

@brucejo75
Thanks for this tip. Works like a charm for us 👍
Since I noticed that after the first reload the HTML/CSS is still the 'old' version of my app but the React components are actually already on the new version I thought I can make use of that 'feature' and implement as follows:

Created a Meteor method that checks a sent version against the current server version.

reloadRequired: function(buildCode) {
        if (!buildCode || Meteor.settings.public.build > buildCode) {
            console.log('reload required for App with buildcode', buildCode);
            return true;
        } else {
            return false;
        }
    }

From a React component that is already loaded by the first version of my app on my login screen (the first screen of the app) I call this Method in the _componentDidMount()_ lifecycle function.

componentDidMount() {
        if(Meteor.isCordova && 'android' === device.platform.toLowerCase()) {
            Meteor.setTimeout(() => {
                Meteor.call('reloadRequired', Meteor.settings.public.build, (e,result) => {
                    if(!e && result) {
                        location.reload();
                    }
                });
            }, 10000);
        }
    }

Note that the build code already was part of my settings file used to build the initial App Store version of the app. But even if you don't have that implemented yet I believe you can use the above code as long as you have an existing React component - preferably on the first page of your app.

Nauzer on 17 Mar 2019

@wildhart, were you able to solve the cache?

rj-david on 21 Mar 2019

No, I haven't been able to play with the nginx cache yet, and I'm on vacation now until April..

wildhart on 21 Mar 2019

Sorry for the haitus. I've been able to access the iOS logs and confirmed the findings of @rj-david https://github.com/meteor/meteor/issues/10277#issuecomment-471980580, that iOS is caching the /__cordova/manifest.json file after the first HCP.

Using MUP I've managed to prevent the cache and finally got HCP working on iOS again. See my MUP bug report/suggestion here: https://github.com/zodern/meteor-up/issues/1086

wildhart on 21 May 2019

@wildhart we seem to have resolved our issue using a similar approach using Cloudflare (setting a Page rule which bypasses the cache for any requestions to .ourdomain.com//manifest.json).

@benjamn I'm guessing it should be possible to set the Cache-Control headers on the side of Meteor, but am not sure where to look; any pointers?

KoenLav on 23 May 2019

@KoenLav I'm investigating a new HCP problem on iOS that we are having but I already change the Cache-Control in my Meteor app for static assets like this

WebApp.rawConnectHandlers.use((req, res, next) => {
  if (
    req._parsedUrl.pathname.match(/\.(jpe?g|png|gif|svg|eot|ttf|woff|woff2)$/i)
  ) {
    // one year
    res.setHeader('Cache-Control', `max-age=${OFFLINE_CACHE_EXPIRE}`);
  }
  next();
});

filipenevola on 23 May 2019

I added this but my HCP still not working on iOS (Meteor 1.8) but it was working until a few weeks ago, then I guess my problem is different

  if (req._parsedUrl.pathname.match(/manifest\.json$/i)) {
    // https://github.com/zodern/meteor-up/issues/1086
    // no cache for /__cordova/manifest.json
    res.setHeader(
      'Cache-Control',
      'no-store, no-cache, must-revalidate, proxy-revalidate, max-age=0'
    );
  }

filipenevola on 23 May 2019

@filipenevola, I'm pretty sure the /__cordova files are not served through the WebApp handlers.

I've confirmed this on localhost by using

WebApp.connectHandlers.use((req, res, next) => {
    console.log(req._parsedUrl.pathname);
    next();
});

And the lack of console messages confirms that the handler is not being called on the /__cordova/manifest.json file.

You can check for yourself: in Chrome navigate direct to your manifest.json file and look at the network tab of Dev Tools. You will only see cache-control: public, max-age=31536000

The extra Cache-Control header needs to be added by the server, unless something can be done at a lower level in Meteor by @benjamn...

wildhart on 23 May 2019

@wildhart I checked this but I got the opposite. I was able to see it affecting the requests on Chrome and also logs in the server.

Are you importing the file with this WebApp.connectHandlers code on server side startup?

filipenevola on 23 May 2019

@filipenevola, yes my test WebApp.connectHandlers code is imported into the server bundle. I can see the console messages when I browse to routes in my app but not when I browse to the manifest.js file. Interesting that you do.

So you've confirmed that your server is now sending the manifest with the correct no-store, no-cache header, but iOS still isn't updating the HCP, correct? Have you tried uninstalling the iOS app from the device and reinstalling it? Once an install of the app has cached an old manifest nothing you change on the server will make it get a fresh copy until you delete the app.

wildhart on 24 May 2019

Suggestion for @benjamn: Could it be as simple as adding a cache-busting timestamp to the manifest fetch request, making the app always get a fresh copy no matter what caches/proxies are in the way?
https://github.com/meteor/meteor/blob/5dcd0b2eb9c8bf881ffbee98bc4cb7631772c4da/packages/webapp/webapp_server.js#L721

Change to:

    const manifestUrl = manifestUrlPrefix + getItemPathname("/manifest.json") + '?' + new Date().valueOf();

wildhart on 24 May 2019

@wildhart Yes, I had uninstalled but I don't know why it is not working, we are updating to Meteor 1.8.1 to see if it's working there.

filipenevola on 24 May 2019

@wildhart, did you fork the webapp package and give your fix a try?

It is pretty simple to do without rebuilding all of meteor:

clone meteor
copy the webapp package into your project
make modifications to the package
I usually make sure the package is referred to directly in .meteor/packages
give it a build and your new code will be used.

Then if it works, copy your fixes back to a PR branch on your meteor clone and submit a pull request.

brucejo75 on 24 May 2019

@wildhart my HCP are working now and the only change I did was the manifest cache one, I think something was still caching last time I tried and today I'm really cache free.

Just to be clear for future people, my only change was this on server side of my Meteor app

WebApp.rawConnectHandlers.use((req, res, next) => {
  if (req._parsedUrl.pathname.match(/manifest\.json$/i)) {
    // eslint-disable-next-line no-console
    console.log('requesting manifest.json', req._parsedUrl.pathname);
    // https://github.com/zodern/meteor-up/issues/1086
    // no cache for /__cordova/manifest.json
    res.setHeader(
      'Cache-Control',
      'no-store, no-cache, must-revalidate, proxy-revalidate, max-age=0'
    );
  }
  next();
});

filipenevola on 27 May 2019

👍1

@filipenevola this seems like a change that should be integrated into Meteor; could you make a PR?

@benjamn could you confirm?

KoenLav on 27 May 2019

@KoenLav sure.

Let's wait for Ben first.

filipenevola on 27 May 2019

@filipenevola's, I've discovered why your solution wasn't having any effect for me. You were using WebApp.rawConnectHandlers but I was using WebApp.connectHandlers. When I use the raw version it works fine (on localhost, haven't tried production).

@brucejo75, I haven't tested my suggestion, and unfortunately at the moment I don't really have time to - to test it properly involves spinning up staging servers and compiling apps in xCode all of which is time consuming. Might have time at the weekend... I figured that Ben would know instantly whether it would work or not, or if there are any unintended consequences I'm not aware of.

wildhart on 28 May 2019

👍1

I've discovered that my errant cache-control: public, max-age=31536000 header was self-inflicted. I had included is as part of my CDN configuration, in a separate file I found this:

WebApp.rawConnectHandlers.use(function(req, res, next) {
    res.setHeader('Access-Control-Allow-Origin', '*');
    res.setHeader("Access-Control-Allow-Methods", "GET,HEAD,OPTIONS,POST,PUT");
    res.setHeader("Access-Control-Allow-Headers", "Origin, X-Requested-With, Content-Type, Accept, Authorization");
    if (req._parsedUrl.pathname.match(/\.(js|font\.css|css|jpg|png|ttf|ttc|otf|eot|woff|woff2|json)$/)) {
        res.setHeader('cache-control', 'public, max-age=31536000');
    } 
    next();
});

I must've picked that code up from a guide or forum when I first implemented a CDN years ago.

I've now fixed it to this:

WebApp.rawConnectHandlers.use(function(req, res, next) {
    res.setHeader('Access-Control-Allow-Origin', '*');
    res.setHeader("Access-Control-Allow-Methods", "GET,HEAD,OPTIONS,POST,PUT");
    res.setHeader("Access-Control-Allow-Headers", "Origin, X-Requested-With, Content-Type, Accept, Authorization");
    if (req._parsedUrl.pathname.match(/\.json$/)) {
        res.setHeader('Cache-Control', 'no-store, no-cache, must-revalidate, proxy-revalidate, max-age=0');
    } else if (req._parsedUrl.pathname.match(/\.(js|font\.css|css|jpg|png|ttf|ttc|otf|eot|woff|woff2)$/)) {
        res.setHeader('cache-control', 'public, max-age=31536000');
    }
    next();
});

So apologies for suggesting that Meteor and/or MUP were inserting this header, it was me all along. Maybe Meteor/MUP don't need to fix anything, or maybe it would be wise for them to add appropariate default 'no-cache' headers anyway...

wildhart on 28 May 2019

👍4 🎉1

Is this still open for a year now?

derwaldgeist on 26 Oct 2019

👎1

No! It’s fixed in v1.7.0 of the plugin. I think other linked tickets give the whole story.

On Oct 26, 2019, at 8:35 AM, Tom Brückner notifications@github.com wrote:

Is this still open for a year now?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.

RealHandy on 26 Oct 2019

👍1

Hello, AFAIK this is working.

I'm going to close this but if someone is still having issues please reply here.

filipenevola on 19 Nov 2019

Meteor: Hot Code Push broken on iOS

Most helpful comment

All 134 comments

Update

Update

Repro steps

Observation

Workaround

Workaround

Related issues