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

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.

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

[locks]

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