Wrong 'this' in a service using Ivy

[waterplea]

🐞 bug report

Affected Package

@angular/core

Is this a regression?

Yes, the previous version in which this bug was not present was: 8

Description

I have a service abstraction over ngOnDestroy to unsubscribe from streams. Here's its source code, it's pretty simple:

@Injectable()
export class DestroyService extends Observable<void> implements OnDestroy {
    private readonly life$ = new Subject<void>();

    constructor() {
        super(subscriber => this.life$.subscribe(subscriber));
    }

    ngOnDestroy() {
        this.life$.next();
        this.life$.complete();
    }
}

I have it in my library of UI components that I compile with Angular 7/8. After I tried it with Angular 9 RC application (tried with 14 and with some old ones) — when a component (from my library) using that service gets destroyed I get an error Cannot read property 'next' of undefined. Setting breakpoints shown me that this inside this service is, for some reason, component instance that uses it, not the service instance.

🔬 Minimal Reproduction

I was unable to reproduce it in an isolated environment but I have no clue how this could have happened. My code is proprietary which I'm struggling to open source but it takes a while. I was hoping maybe somebody from Angular team who knows Ivy compiler and ngcc have any ideas how this could have theoretically happened.

🔥 Exception or Error

This inside ngOnDestroy of a service is component instance, not service instance

🌍 Your Environment

Angular Version:

Angular 9.0.0-rc.14!

Anything else relevant?
Sorry for such a vague description, the library is pretty straightforward Angular CLI library compiled with ng-packagr. It's just really huge and when I try to make a small library with relevant code — the issue does not reproduce. Without deep knowledge of how ngOnDestroy gets called I failed to debug it on my side.

[crisbeto]

How is the service being consumed? Are components extending it? I tried to reproduce it in a test like this, but it was behaving correctly. The logs is [Comp, InjectableWithHook]:

fit('', () => {
  const logs: any[] = [];

  @Injectable()
  class InjectableWithDestroyHook {
    ngOnDestroy() { logs.push(this); }
  }

  @Component({selector: 'comp', template: ''})
  class Comp extends InjectableWithDestroyHook {
  }

  @Component({template: '<comp></comp>', providers: [InjectableWithDestroyHook]})
  class App {
    constructor(foo: InjectableWithDestroyHook) {}
  }

  TestBed.configureTestingModule({declarations: [App, Comp]});
  const fixture = TestBed.createComponent(App);
  fixture.detectChanges();
  fixture.destroy();

  console.log(logs);
});

[waterplea]

I've spent last two days trying to isolate it but I couldn't. Tried compiling smaller libraries with all the same versions but it wasn't reproducible :(

This is what I have:
https://ng-run.com/edit/Ukg0KPRiI0WMpdVaTWDc?open=app%2Fapp.module.ts&aot=true

There are 2 libraries in a workplace. One has services and a directive, second library has components that use that directive. When I compile both libraries and try to use those components in an Ivy application I get that error on destroy.

I'm going to try and debug it more, so far I'm clueless...

[waterplea]

I got it reproduced, it happens in plain Ivy if you have two directives using the same service on the same element:

https://ng-run.com/edit/Ukg0KPRiI0WMpdVaTWDc?open=app%2Fapp.component.html&aot=true

Here you have a service listening to some events using that DestroyService as takeUntil and passing results to the directive. I've made two dummy directives like that, one listening to clicks and another listens to mousedowns, it doesn't really matter what they do. If you put one of them on an element it all works fine. But if you put both on the same element and that element disappears (click the button on the example) — then the error is shown. executeOnDestroys function from core.js gets wrong context in this line:
var context = view[destroyHooks[i]];

[angular-automatic-lock-bot]

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}