Ember.js: 1.11.3 update - Uncaught Error: Assertion Failed: calling set on destroyed object

Created on 6 May 2015  路  19Comments  路  Source: emberjs/ember.js

I'm getting this error on v1.11.3 and it's not happening in v1.10.1:

screen shot 2015-05-06 at 2 54 31 pm

Any help would be greatly appreciated as it's preventing me from updating to v.1.11.3.

Needs Submitter Response

All 19 comments

Same result with v1.12.0-beta.3

Seem to be getting a similar error on an alternate route:

screen shot 2015-05-06 at 3 21 16 pm

Again, only in versions after 1.10.1.

Can you provide a reproduction/demo? It will be very hard to track down the solution for your scenario without one....

Can you provide a reproduction/demo?

Closest I can find is this StackOverflow Question which links to this JSBin.

[From the Question] ... To see the effect uncomment the second ContainerView and comment out the first, you will notice in the console logs that the second time you go to the twoRoute, it has marked that initial property as state: destroying for the view.

The problem with this example is that I do not have anything being defined in this manner in my application.

Tests reveal that this only happens when you visit the route a _second_ time after leaving this specific route.

After an entire day of diagnosis, I have been able to fix this on one of my routes by removing this:

// route code
setupController: function(controller, model){
    this._super(controller, model);

    controller.setProperties({
        "model": model,
        "searchLimitReached": false,
        "leadResults": []
    });
},
/// other route code

This isn't desired as I need to set properties on returning to this route.

Some additional details using this code:

  setupController: function(controller, model){
    this._super(controller, model);

    /* */
    console.log(
      "%c%s#setupController controller: %s, %O",
      "color: purple", // http://www.w3schools.com/html/html_colornames.asp
      this.toString(),
      controller.toString(),
      controller.getProperties('isDestroyed', 'isDestroying')
    );
    //*/

    /*
     controller.setProperties({
      "searchLimitReached": false,
      "leadResults": []
    });
    */

    /* */
    console.log(
      "%c%s#setupController Complete...",
      "color: purple", // http://www.w3schools.com/html/html_colornames.asp
      this.toString()
    );
    //*/
  },

I get no error as follows:

screen shot 2015-05-07 at 3 20 43 pm

But if I uncomment the controller.setProperties():

screen shot 2015-05-07 at 3 19 53 pm

The expanded error:

screen shot 2015-05-07 at 3 27 13 pm

Hoping this helps diagnose.

My guess: your test is not waiting for the model hook promise to resolve, which means that the test has already been torn down (and therefore controller is destroyed) when the setProperties is called.

This error only happens _upon returning_ to the route after the first time you visit it and then navigate away. The first time goes without a hitch. I'm assuming because it's creating a new instance of the controller for that first time and trying to re-use it the second. The model hook is simply returning all models of a specific type so it instantly resolves:

  model: function(){
    return this.store.all('liveCall');
  }

I can reproduce this error on all routes that have controller.setProperties() in their setupController hook. I can also remedy it by removing the controller.setProperties(). Some routes model hooks return that.store.all() some use return that.store.find(). I'm using return this.store.all() because I have an infinite scroller loading _pages_ of the models into the store.

Why would this have changed from v1.10.1 (where I had no error) to 1.11.3? If I rebuild with v1.10.1 I do not get any errors.

This is directly related to the above code and the controller.setProperties(). I can reproduce this error on _any_ route in my application that has controller.setProperties() in the setupController hook. Then I can clear it up by removing the controller.setProperties().

I attempted to move the controller.setProperties() inside a Ember.run.later() to see if I wait to set the variables it would avoid this error but once the controller.setProperties() runs I get the same error (not surprising but I'm attempting anything to get this to work).

the test has already been torn down (and therefore controller is destroyed) when the setProperties is called

When returning to the route wouldn't the controller be re-setup? I'm a little confused why this would work fine in v1.10.1 and not in v1.11.3 since the setupController hook is where you are _supposed to_ do this type of variable setting on your controller.

I've tried to create a JSBin to duplicate this issue but am unable to duplicate it. JSBin here. The differences between the JSBin and my application are that I'm using Ember CLI (v0.2.3) to build, using the REST adapter rather than the Fixtures adapter, and my routes are nested a few steps deeper.

Interestingly, once this error happens I can still navigate my application but the entire Ember Data layer is disabled. Assuming this is because the Ember Data script errored out.

I was able to gain some insight to this error by modifying this line to:

    if(obj.isDestroyed){
      console.log(obj);
    }
    Ember['default'].assert("calling set `" + keyName + "` on destroyed object", !obj.isDestroyed);

This JSBin now produces the error.

To duplicate: Navigate to route one, then route two, then back to route one to duplicate.

This is a widespread problem all over my application. Any help would be greatly appreciated. It's holding further development back. Thanks.

Also applies to the new 1.12.0.

I have also found that if I wrap my {{each}} in an {{if}} then it doesn't happen. Rather than using the {{each}} {{else}} option.

Above is inconsistent and works _sometimes_.

It can be seen with This Bin.

However if you comment out the todos from the user model then all goes fine.

More updates... I have found that it only happens on routes that have an Ember form element in my application (e.g, {{input}}) on them. It seems they don't get torn down correctly. If I wrap the entire template in {{#if model}}...{{/if}} I do not get the error.

if you are using Ember.Instrumentation namespace for publishing your events and Ember.subscribe to listen to them in your code, when you publish events then it stack all the subscribers and call them even when they are destroyed. so basically, when for example your route is destroyed which is running subscribe statements it will fail and give above error.

Here is a solution to this problem. Use Ember.Instrumentation.reset() to remove previous subscribers which are destroyed. This solution helped me in acceptance tests where app was destroyed after tests are finished. I wrote Ember.Instrumentation.reset() in startApp function of module-for-acceptance.js and it worked. Hope that helps.

I'm having the same problem, on a component that's initialized within a tabs component, didInsirtElement and similar hooks get called twice for some reason, first time is correct and second time with an element gets destroyed.

Assertion Failed: calling set on destroyed object

Was this page helpful?
0 / 5 - 0 ratings

Related issues

workmanw picture workmanw  路  79Comments

fivetanley picture fivetanley  路  44Comments

MelSumner picture MelSumner  路  33Comments

skoryky picture skoryky  路  50Comments

chancancode picture chancancode  路  63Comments