Hot Code Push broken on iOS

EliArtist commented 5 years ago

My iOS app can't use hot code push to get new versions I upload. After some searching I believe I can narrow down the problem to a bug in cordova-plugin-meteor-webapp which tries to link the same file twice. I'm pretty sure that is what breaks hot code push. I found a similar issue here: https://github.com/meteor/cordova-plugin-meteor-webapp But that repository is untouched since February so I decided to open a new issue here.

My current Meteor version is 1.7.1-rc.5, I'll try to update the meteor version to 1.8, test again and post an update here.

EDIT: After trying to build an iOS App with Meteor 1.8 I'm getting the same error

rj-david commented 5 years ago

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

RealHandy commented 5 years ago

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.

rj-david commented 5 years ago

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

RealHandy commented 5 years ago

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.

buymybm100 commented 5 years ago

@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.

brucejo75 commented 5 years ago

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.

rj-david commented 5 years ago

@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:

branch-cordova-sdk@3.1.5
cordova-plugin-camera@4.0.3
cordova-plugin-datepicker@0.9.3
cordova-plugin-device@2.0.2
cordova-plugin-file@6.0.1
cordova-plugin-filepath@1.5.1
cordova-plugin-geolocation@4.0.1
cordova-plugin-inappbrowser@3.0.0
cordova-plugin-ionic-keyboard@2.1.3
cordova-plugin-nativestorage@2.3.2
cordova-plugin-splashscreen@5.0.2
cordova-plugin-statusbar@2.4.2
cordova-plugin-vibration@3.1.0
cordova-plugin-wkwebview-engine@1.1.4
cordova-plugin-x-socialsharing@5.4.4
onesignal-cordova-plugin@2.4.6
phonegap-plugin-barcodescanner@8.0.1

rj-david commented 5 years ago

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?

mozfet commented 5 years ago

@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 commented 5 years ago

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?

menelike commented 5 years ago

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.

mozfet commented 5 years ago

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).

rj-david commented 5 years ago

@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 commented 5 years ago

@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: cordova-plugin-device@2.0.2 cordova-plugin-file@6.0.1 cordova-plugin-inappbrowser@3.0.0 cordova-plugin-splashscreen@5.0.2 cordova-plugin-statusbar@2.4.2

menelike commented 5 years ago

@mozfet

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

Nauzer commented 5 years ago

Hi @rj-david @mozfet @wildhart

Try adding the latest version of cordova-plugin-meteor-webapp to your cordova plugins list. cordova-plugin-meteor-webapp@1.6.5

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 commented 5 years ago

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?

mozfet commented 5 years ago

@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.

menelike commented 5 years ago

@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.

mozfet commented 5 years ago

@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...

rj-david commented 5 years ago

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"}

menelike commented 5 years ago

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

Nauzer commented 5 years ago

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" } }

rj-david commented 5 years ago

@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

menelike commented 5 years ago

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.

rj-david commented 5 years ago

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 commented 5 years ago

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)

menelike commented 5 years ago

@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....

rj-david commented 5 years ago

@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)

menelike commented 5 years ago

@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).

wildhart commented 5 years ago

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 cordova-plugin-meteor-webapp@1.6.5: https://pastebin.com/yYvNG9sK

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

rj-david commented 5 years ago

@RealHandy, you might be more familiar with this:

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

rj-david commented 5 years ago

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 commented 5 years ago

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":"METEOR@1.8.1-beta.20",
"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 commented 5 years ago

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 commented 5 years ago

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

mozfet commented 5 years ago

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

Nauzer commented 5 years ago

@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 =

mozfet commented 5 years ago

@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>

Nauzer commented 5 years ago

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.

RealHandy commented 5 years ago

@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.

wildhart commented 5 years ago

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?

mozfet commented 5 years ago

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

RealHandy commented 5 years ago

@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.

Nauzer commented 5 years ago

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

rj-david commented 5 years ago

@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 commented 5 years ago

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.

Nauzer commented 5 years ago

@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.

brucejo75 commented 5 years ago

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.

menelike commented 5 years ago

@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.

meteor / meteor