New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Meteor Cordova app still tries to connect to local server after a build with --server option. #7849

Closed
dagatsoin opened this Issue Sep 30, 2016 · 19 comments

Comments

Projects
None yet
8 participants
@dagatsoin

dagatsoin commented Sep 30, 2016

  • METEOR@1.4.1.1
  • ROOT_URL (on server) is set to: X.X.X.X:8080
  • Build command of the server: meteor build app/ --directory --server-only --server 0.0.0.0:8080

(Xpost with an SO question, but I suspect an issue)

I build my meteor cordova app with meteor build ../output --server myserverprod.com:8080

Then I upload the android-armv7-debug.apk to an FTP and redownload it on my devices.

But when I remote debugging I see that it still tries to connect to my local server 192.x.x.x instead of the URL I put in the command line.

I also tested by disable wifi to be sure that it happens with the initial embedded files.

Is there any environment variable to set which are not documented?

@abernix

This comment has been minimized.

Member

abernix commented Sep 30, 2016

I realize the docs don't make this 100% clear, but make sure that your ROOT_URL includes the protocol (e.g. https://, http://) and the same with the --server argument when building. (ROOT_URL=http://myserverprod.com:8080 and --server https://mysererprod.com:8080)

Also...

Run command of the server: meteor build app/ --directory --server-only --server 0.0.0.0:8080

This command will simply generate a bundle directory of a Node app; this is not a "Run command". Additionally, the --server is actually not relevant on this command (only used on the mobile build). In the output bundle directory, you'll find a README with instructions on how to run the Node server. When starting, you'll define the ROOT_URL which should match the --server you used when generating the mobile bundle.

@dagatsoin

This comment has been minimized.

dagatsoin commented Sep 30, 2016

@abernix Note that the doc is also different form the command line help.
The command line says we must write --server**=** and the doc says to use a space. So which one is right?

I will double check the protocol.

@abernix

This comment has been minimized.

Member

abernix commented Sep 30, 2016

Either should work, but its been suggested that there is a bug with that logic: #7112. (Though, the reproduction steps did not work for me last I tried). Please do report over there if you experience the same behavior.

@dagatsoin

This comment has been minimized.

dagatsoin commented Sep 30, 2016

EDIT: corrected my first post bout run/build.

I did not write the port in ROOT_URL. I will see if it fixes.

@abernix

This comment has been minimized.

Member

abernix commented Sep 30, 2016

Please also make sure you're starting the node process as suggested in the README:

  $ (cd programs/server && npm install)
  $ export MONGO_URL='mongodb://user:password@host:port/databasename'
  $ export ROOT_URL='http://example.com' # <===== You can also add :PORT here if necessary.
  $ export MAIL_URL='smtp://user:password@mailhost:port/'
  $ node main.js
@dagatsoin

This comment has been minimized.

dagatsoin commented Sep 30, 2016

I am pretty sure the issue does not come from the server.

  1. I put my mobile device offline (no wifi)
  2. I ran meteor build ../build --server http://xxx.io:8080
  3. I ran adb install ../build/android/project/build/outputs/apk/android-armv7-debug.apk
  4. Under chrome remote debugging I have a list of:
GET http://192.168.1.54:3000/sockjs/info?cb=aw_8fiqdm3 net::ERR_ADDRESS_UNREACHABLE
AbstractXHRObject._start @ ddp-client.js?hash=2750240…:942
(anonymous function) @ ddp-client.js?hash=2750240…:976

http://192.168.1.54 is the local dev server address (which I stopped).

@dagatsoin

This comment has been minimized.

dagatsoin commented Sep 30, 2016

Whaou, I don't understand anything !
I did a meteor reset. Now, when I do meteor build .... I can't find any apk...

I have a lot of warnings, but no fatal error preventing the build.

EDIT: ok, no, I am just tired after waiting all the day to find what is going wrong and I made a typo in the command path.

@dagatsoin

This comment has been minimized.

dagatsoin commented Sep 30, 2016

OK, I have a workaround and repro steps.

Repro

  1. Reset or create a new project
  2. Add android platform
  3. meteor run android device
  4. meteor build ../apk --server http://whatever.com:3000 and install the apk with adb install ../apk/...
  5. Remote debug shows the app is trying to connect to the old local url.

It is like meteor build keep the previous url (so the local one)

workaround

  1. meteor run android-device --mobile-server http://whatever.com:3000
  2. meteor build ../apk --server http://whatever.com:3000 and install the apk with adb install ../apk/...
  3. Remote debug shows the app connect to whatever.com

cc @abernix @martijnwalraven

@indesignlatam

This comment has been minimized.

indesignlatam commented Sep 30, 2016

I have had a similar problem when building, sometimes it connects correctly but sometimes it just connects to localhost. The only thing i do solve this is run build again, with the same command and it just works the 2nd or 3rd time.

I havent figured out how to reproduce it with a new project.

@dagatsoin

This comment has been minimized.

dagatsoin commented Oct 26, 2016

@ramezrafla

This comment has been minimized.

Contributor

ramezrafla commented Nov 4, 2016

We had the same issue and it was repeatable. You need to do a reset every time you make a serious change before recompiling for mobile (e.g. of a serious change, switching from dev to production, switching between localhost and server).

Secondly, almost always, after a reset, the first build fails, but second onwards work.

abernix added a commit to abernix/meteor that referenced this issue Dec 12, 2016

Cordova project preparation must occur before copying to the build
This fixes a regression caused by 88d43a0 which is demonstrated in meteor#7849.

Essentially, with the current implementation some Cordova build elements are "stale" when the build is copied.  For example, if you execute a `meteor run ios` and then `meteor build . --server=http://example.com/` (note: `example.com`) the `config.xml` (`<access origin />`), the boilerplate HTML (`__meteor_runtime_config__`) and other elements of the bundle (`Info.plist` on iOS) will still contain the previously used `http://<local_ip>:3000` address instead of `http://example.com` as they should.

Additionally, it would appear that it's impossible to actually checkout a project and immediately run `meteor build` without running `meteor run (android|ios)` first.

Various work-arounds for this seem to exist, such as running `meteor build` twice, or running `meteor run --server=http://production.com` first.

Ultimately, this is occurring because the bundle is being copied before the Cordova `prepareForPlatform` occurs which I believe was not the intended.

There is already a test in place which fails without this fix, but they are marked as `slow` and therefore not executed on CircleCI.  Specifically, `cordova builds with server options` would have caught this.  Forcibly running this test locally now passes with this change.

Fixes meteor#7849
Fixes meteor#7291
Fixes meteor#6756

abernix added a commit to abernix/meteor that referenced this issue Dec 12, 2016

Cordova project preparation must occur before copying to the build
This fixes a regression caused by 88d43a0 which is demonstrated in meteor#7849.

Essentially, with the current implementation some Cordova build elements are "stale" when the build is copied.  For example, if you execute a `meteor run ios` and then `meteor build . --server=http://example.com/` (note: `example.com`) the `config.xml` (`<access origin />`), the boilerplate HTML (`__meteor_runtime_config__`) and other elements of the bundle (`Info.plist` on iOS) will still contain the previously used `http://<local_ip>:3000` address instead of `http://example.com` as they should.

Additionally, it would appear that it's impossible to actually checkout a project and immediately run `meteor build` without running `meteor run (android|ios)` first.

Various work-arounds for this seem to exist, such as running `meteor build` twice, or running `meteor run --server=http://production.com` first.

Ultimately, this is occurring because the bundle is being copied before the Cordova `prepareForPlatform` occurs which I believe was not the intended.

There is already a test in place which fails without this fix, but they are marked as `slow` and therefore not executed on CircleCI.  Specifically, `cordova builds with server options` would have caught this.  Forcibly running this test locally now passes with this change.

Fixes meteor#7849
Fixes meteor#7291
Fixes meteor#6756

abernix added a commit to abernix/meteor that referenced this issue Dec 12, 2016

Cordova project preparation must occur before copying to the build
This fixes a regression caused by 88d43a0 which is demonstrated in meteor#7849.

Essentially, with the current implementation some Cordova build elements are "stale" when the build is copied.  For example, if you execute a `meteor run ios` and then `meteor build . --server=http://example.com/` (note: `example.com`) the `config.xml` (`<access origin />`), the boilerplate HTML (`__meteor_runtime_config__`) and other elements of the bundle (`Info.plist` on iOS) will still contain the previously used `http://<local_ip>:3000` address instead of `http://example.com` as they should.

Additionally, it would appear that it's impossible to actually checkout a project and immediately run `meteor build` without running `meteor run (android|ios)` first.

Various work-arounds for this seem to exist, such as running `meteor build` twice, or running `meteor run --server=http://production.com` first.

Ultimately, this is occurring because the bundle is being copied before the Cordova `prepareForPlatform` occurs which I believe was not intended.

There is already a test in place which fails without this fix, but marked as `slow` and therefore not executed on CircleCI.  Specifically, `cordova builds with server options` would have caught this.  Forcibly running this test locally now passes with this change.

Fixes meteor#7849
Fixes meteor#7291
Fixes meteor#6756
@abernix

This comment has been minimized.

Member

abernix commented Dec 12, 2016

@dagatsoin Thanks very much for the reproduction. I found the cause of this and opened the above PR.

@ramezrafla I believe this is precisely the cause of that problem so please keep your eye on that PR and see if it solves the problem for you!

@benjamn benjamn added this to the Release 1.4.2.x milestone Feb 1, 2017

@bevinhex

This comment has been minimized.

bevinhex commented Mar 13, 2017

Got the same problem here with latest version 1.4.x, spent last two month developing and testing , spent last week searching for possible solutions, still no luck , meteor can get really annoying(unstable) at times.
Mobile version keep complaining about can't connect to localhost:12592 something.

@mackbrowne

This comment has been minimized.

mackbrowne commented Apr 4, 2017

@abernix @bevinhex I'm getting this issue. Pretty aggravating. It seemed to work earlier today and suddenly stopped.

Using Meteor 1.4.3.2
I've Tried:

  • Meteor Reset + new Meteor Build
  • Building multiple times

Not sure what to do, I really need to get this working soon...

@abernix

This comment has been minimized.

Member

abernix commented Apr 5, 2017

@mackbrowne If you provide explicit, step-by-step instructions from a fresh project, I'd be willing to try making another attempt at reproducing this, but as you can see I was already able to reproduce the problem and resolve it to the best of my knowledge. You haven't included information on your testing conditions/environment either.

@mackbrowne

This comment has been minimized.

mackbrowne commented Apr 5, 2017

@abernix I'm investigating the certificate right now. I tested a few different URLS and only the ones with HTTPS weren't working. Thanks for the reply, but for now I think my issue is unrelated. Sorry about that!

@mackbrowne

This comment has been minimized.

mackbrowne commented Apr 6, 2017

@abernix it was a certificate issue that was affecting Android only.

I switched to letsEncrypt and that solved all my issues. @bevinhex, perhaps this may solve your issue as well? I had similar issues to you which is why i replied to this thread in the first place.

@AndyNormore

This comment has been minimized.

AndyNormore commented Aug 13, 2017

This is still an issue. I'll try the workaround. Has caused me a great deal of annoyance... please fix! :)

@AndyNormore

This comment has been minimized.

AndyNormore commented Aug 13, 2017

So I've been using my Mac as the 'be all build all', but I think Mac secretly hates android stuff.

Because it compiles PERFECT on my windows pc.

So I guess Windows builds android, and mac to mac... Exact same code. So it MUST be a build cache.

Perhaps ill build a brand new meteor project, reimport code, and try again.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment