_emberMetalProperty_get.get(...).getURL is not a function

[tschoartschi]

When there is an error in an instance-initializer a very unhelpful exception is thrown. You will get the following stacktrace:

TypeError: _emberMetalProperty_get.get(...).getURL is not a function
    at [object Object].<anonymous> (.../fastboot-tryout/dist/fastboot/vendor.js:37104:60)
    at Descriptor.ComputedPropertyPrototype.get (.../fastboot-tryout/dist/fastboot/vendor.js:24406:28)
    at Object.get (.../fastboot-tryout/dist/fastboot/vendor.js:30060:19)
    at [object Object]._emberApplicationSystemEngineInstance.default.extend.getURL (.../fastboot-tryout/dist/fastboot/vendor.js:14143:38)
    at Result._finalizeMetadata (.../fastboot-tryout/node_modules/ember-cli-fastboot/node_modules/fastboot-express-middleware/node_modules/fastboot/lib/result.js:74:25)
    at Result._finalize (.../fastboot-tryout/node_modules/ember-cli-fastboot/node_modules/fastboot-express-middleware/node_modules/fastboot/lib/result.js:64:12)
    at .../fastboot-tryout/node_modules/ember-cli-fastboot/node_modules/fastboot-express-middleware/node_modules/fastboot/lib/ember-app.js:225:26
    at tryCatch (.../fastboot-tryout/dist/fastboot/vendor.js:61543:14)
    at invokeCallback (.../fastboot-tryout/dist/fastboot/vendor.js:61558:15)
    at publish (.../fastboot-tryout/dist/fastboot/vendor.js:61526:9)
    at .../fastboot-tryout/dist/fastboot/vendor.js:41428:7
    at Queue.invokeWithOnError (.../fastboot-tryout/dist/fastboot/vendor.js:10468:18)
    at Object.Queue.flush (.../fastboot-tryout/dist/fastboot/vendor.js:10523:11)
    at Object.DeferredActionQueues.flush (.../fastboot-tryout/dist/fastboot/vendor.js:10331:17)
    at Object.Backburner.end (.../fastboot-tryout/dist/fastboot/vendor.js:10686:25)
    at [object Object]._onTimeout (.../fastboot-tryout/dist/fastboot/vendor.js:11252:18)

The real error is kind of "swallowed" and very very hard to find. What happens behind the scene is the following:

The error is kind of caught in a promise and the reject callback in rsvp/-internal is called. This happens in initializePromise with reject(promise, e) for more details see the screenshot of the stack trace. At this point the correct error is "caught"

If you continue to step through the program there is going on a lot behind the scenes, like flushing the queues etc. At the end fastboot/lib/result.js calls the _finalize method and then _finalizeMetadata. _finalizeMetadata calls instance.getURL() and then for some reason getURL does not work because it is undefined. If there is no error during instance initializing then the stack trace looks almost the same and instance.getURL() works as expected.

The main problem with this issue is, that the stack trace to _emberMetalProperty_get.get(...).getURL is not a function is totally misleading. I digged around in all of the dependencies because the stack trace never pointed to my own source files and I was really lost. It was just coincidence that I had a break point in rsvp/-internal at the reject callback. I'm not sure if it is a bug but it makes getting fastboot to work really hard.

Steps to reproduce:

mkdir fastboot-tryout
cd fastboot-tryout/
ember init
ember install ember-cli-fastboot
ember g instance-initializer make-fastboot-fail
vi app/instance-initializers/make-fastboot-fail.js 

write something like the following into make-fastboot-fail.js

export function initialize(/* appInstance */) {
  // appInstance.inject('route', 'foo', 'service:foo');
  if(undef.makeItFail) {
    return;
  }
  // DO SOMETHING
}

export default {
  name: 'make-fastboot-fail',
  initialize
};

Then execute the following commands:

ember fastboot
curl http://localhost:3000/

After that you should see the exception from the beginning of my post. For more details I attached my package.json and bower.json

package.txt
bower.txt

[tschoartschi]

@IAmJulianAcosta it seems my issue is similar to yours (#209). Do you think so too?

[IAmJulianAcosta]

Yes, is a very similar issue.

[tschoartschi]

@IAmJulianAcosta do you have an idea how we could create a pull request which fixes this problem? I'm still not sure what our exact problem is. I think the problem is that the stack trace is misleading and that an error which is caught still causes a crash later on. Do you think it is better to first prevent the app from crashing at all and then focusing on the stack trace?

[IAmJulianAcosta]

I have to recreate the problem again to fix it, but I damaged the VM where I was working with fastboot. Fortunately I documented well this problem and I'll be able to recreate again easily. I'll get in touch with you in ember chat when I have some spare time and we could fix it.

[jasonmit]

When an uncaught exception occurs within an instance initializer, the application instance never finishes setting up and so location is still a string, "none", and not the expected Ember.NoneLocation instance.

Where this begins to show itself is inside the lib/ember-app visit method. The error is handled by assigning it to result.error and immediately followed by invoking result._finalize which in turn invokes instance.getURL which ends up calling the router's url computed property which tries to access the location's url... but location is a string because the router never materialized the location object.

For those stuck, I suggest putting a breakpoint here or logging to the console error. That will give the error that is being swallowed.

[tschoartschi]

For those stuck, I suggest putting a breakpoint here or logging to the console error. That will give the error that is being swallowed.

This is exactly what I've been doing 😉 I think the problem is, that it is super hard to debug (if you don't know all the internals of Ember and Fastboot). I got stuck setting up fastboot for about a week because I always thought it is a problem with Ember Simple Auth. So I was searching for the bug in a spot where it never occurred.

I tried to create a pull request but I'm also not sure how to fix this. Especially because I'm not an expert with all the Ember and Fastboot internals.

[jasonmit]

ember-fastboot/fastboot#71 fixes the issue

[steffansluis]

What is the current state of this? I seem to be running into it while switching to fastboot.

[oskarrough]

Also seeing this in my acceptance tests as of Ember 2.13.2 but I am not using FastBoot.

[oa495]

Same. Running in acceptance tests for ember 2.12.1 but not using FastBoot.

[PriyangaSG]

Same issue while running unit tests for ember 2.14. is there any work around?

[kratiahuja]

Can someone provide a minimal reproduction?

[cahyowhy]

Same Issue here.... Running in acceptance tests for ember 2.17

[lolmaus]

I've been having this error in acceptance tests, unrelated to FastBoot.

The cause of the problem was that I was missing await for visit().

[amk221]

I've been having this error in model tests, unrelated to FastBoot

@lolmaus's unfortunately suggested fix isn't applicable for my case.

[lolmaus]

@amk221 That's weird. Model tests are integration tests, I assume the URL should not be involved in any way.

Can you post your test to https://gist.github.com ?

[amk221]

amk221/-ember-data-geturl-not-a-function@3ab9aa7

[lolmaus]

@amk221 You have a number of issues with your test:

• Your test is async, but you're testing it as sync. It's necessary to add await like I suggested above.
• The foo.bar relationship in your payload fixture is empty, yet you're asserting that it's populated with bar.

I've filed a pull request addressing these and the test is green: https://github.com/amk221/-ember-data-geturl-not-a-function/pull/1/files

That said, the error _emberMetalProperty_get.get(...).getURL is not a function is extremely cryptic and indicates an inner problem with Ember and/or Ember Data. The happy path is fine, but a faulty state is not handled properly and the whole thing blows up instead of gracefully reporting the issue where it actually happens.

Metaphorically speaking, the framework should produce a gag reflex and refuse to swallow a large object. Instead, it swallows the object obediently and dies from intestine blockage.

[amk221]

@lolmaus

• Yes, that's just because I forgot.
  The actual test is much more involved, and this is was a minimal reproduction.
• Yes, that is intentional, that is how the error is triggered.

The actual test does some setting and unsetting of relationships. But still comes back with this error.

However - I've just put two and two together, and I now think that it's related to this issue:

emberjs/data#5517.

i.e. Setting the relationship from null back to an ED model does not work due to the above bug in 5517, therefore, the test ends up deepEqualing an ED model with null, which triggers the error in question.

I've just tried 3.4.0-beta.3 and canary, but the problem still exists.