[3.4.0-beta.2] Cannot update watchers for isVisible on component teardown

[Dhaulagiri]

I'm not sure if I will be able to come up with a concrete, independent reproduction but in the latest 3.4.0 beta I am seeing an error in code that has worked in previous versions of Ember.

The code in question is a computed property on a component where chart.graphs is an array of components.

visibleSiblingGraphs: filterBy('chart.graphs', 'isVisible'),

This triggers this error when, I think, this component is being torn down.

Error: Assertion Failed: Cannot update watchers for `isVisible` on `<my-app@component:my-component::ember1016>` after it has been destroyed.
    at new EmberError (index.js:37)
    at assert (index.js:125)
    at Meta.writeWatching (meta.js:279)
    at unwatchKey (ember-metal.js:1010)
    at unwatch (ember-metal.js:2010)
    at removeObserver (ember-metal.js:1511)
    at removeObserverForContentKey (ember-metal.js:1619)
    at EachProxy.stopObservingContentKey (ember-metal.js:1594)
    at EachProxy.didUnwatchProperty (ember-metal.js:1571)
    at unwatchKey (ember-metal.js:978)

For reasons that aren't clear to me, if I switch to using filter I no longer get the error:

visibleSiblingGraphs: filter('chart.graphs', function(graph) {
    return graph.get('isVisible');
  }),

I'm sure we have many other instances of filterBy in use so something odd must be happening for this case that I can't quite ascertain just yet, but I thought it would helpful to open something in case anybody has any ideas.

[sdhull]

We actually had issues with sortBy that were fixed by switching to sort macro. IIRC it was that they weren't updating in certain circumstances...

[sdhull]

But at any rate, I got here because we recently upgraded to ember 3.2.2 and I just noticed this error cropping up:

"Assertion Failed: Cannot update watchers for `cssString` on `<my-app@component:my-component::ember619>` after it has been destroyed."

In my case, I noticed it happens when I am on a page with {{component 'my-component'}}, I navigate away then I navigate back. The error happens when I navigate back.

[rwjblue]

Would really love a repro here, I'm at a loss and don't really have a guess about whats going on...

[Dhaulagiri]

In the interest of time I had moved past this since we had a bunch of other small things to fix in our app and I had a workaround, but I'll see if I can put something together.

[sdhull]

I tried to build a repro in ember-twiddle for quite some time but failed. I think should should close this issue pending a repro @rwjblue

[danielspaniel]

This is definitely an issue .. don't close this .. i will try to reproduce somehow

[rwjblue]

That would be awesome, thank you for trying! FWIW, I'm totally happy to clone a GH repo to reproduce if that is easier...

[danielspaniel]

interesting .. i found the problem but it might not be a bug bug in ember.

case 1]
for ember simple auth after signing up i assign the user to a service ( let's call it auth )

export default class Auth extends Service {
 @reads('currentUser.company') currentCompany
  
 // after sign up do this 
  async loadCurrentUser(userId) {
      const user = await this.store.findRecord('user', userId);
      this.set('currentUser', user);
   }
}

so, lets say that other components are binding to auth.currentUser
with the usual

 @reads('auth.currentUser') currentUser 

or maybe a

@reads('auth.currentUser.email') currentUserEmail 

and then later you sign out with your basic

   async signOut() {
      await this.session.invalidate();
      this.transitionTo('sign-in');
}

then its fine, and then you sign in again and blam, you get the error
it's like that old user model is still attatched to the auth service ( obviously ) but is now in destroyed state
and before the new user model ( that is loaded ) can replace it, blah .. ember barfs trying to setup watchers on the old user

the solution is to be more mouse like and tip toe around the problem.

 async signOut() {
    this.auth.unloadUser(); // in auth service this method does:  this.set('currentUser, null); 
    await this.session.invalidate();
    this.transitionTo('sign-in');
}

and voila .. problem solved.

case 2] i have an array of models in a weakMap and a component is using that array, and later those models are destroyed. the component freaks out. the answer there is to be more mouselike and before i destroy those array of models to tip toe over to that weakmap and clear them from the array.

[Jamesiebondco]

I just wanted to add a comment. I was suffering from a similar error. On user logout I was unloading a specific model. In a related service I had a computed filter for a list.

list: A(),

computedProperty: computed.filter("list.@each.attributes", function(item) {
  return item.get("attributes.field") && item.get("attributes.value") === "value"
}),

unload() {
  this.set('list', A()); // Without resetting the list referring to the model I received the error.
  this.get('store').unloadAll('model');
},

The above code shows the issue simplified. It was case of the list with reference to unloaded items which was throwing that error.

As above resetting the list when unloading the items solved this for me

[locks]

isVisible is now deprecated, and not present in Glimmer components, so I'm closing this issue. Thanks!