Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

WatchQuery dispose leaking #469

Closed
stephenlautier opened this issue Jan 24, 2018 · 11 comments
Closed

WatchQuery dispose leaking #469

stephenlautier opened this issue Jan 24, 2018 · 11 comments

Comments

@stephenlautier
Copy link
Contributor

stephenlautier commented Jan 24, 2018

When using the .watchQuery, is there a way to dispose it?
Not sure if its a bug or I'm misusing it, but it seems to be leaking without somehow disposing it.

I followed the documentation but all the usages doesnt have any dispose, I also unsubscribe from the .valueChanges.subscribe but it's still alive.

This is what I'm doing:

  • Register WatchQuery
    • On page init
    • Invoke watchQuery
    • Add log
    • subscribe to .valueChanges
  • Change page
    • On page destroy
    • Unsubscribe to valueChanges subscription
  • Revisit page with watchQuery
  • Reset Store (via getClient().resetStore())
  • Log gets called x2 instead (increasing for every page switch)

image

If you would like to see how I'm using it exactly you can do so on https://github.com/sketch7/angular-skeleton-app/blob/feature/odin-gql/src/app/areas/heroes/heroes.component.ts#L30
Unfortunately on that branch, with the API you cannot just run it.
p.s. I also tried to put everything in the UI for the sake of it, but same issue

@kamilkisiela
Copy link
Owner

kamilkisiela commented Jan 27, 2018

I failed to reproduce it by simply using Apollo service inside a component.

https://stackblitz.com/edit/apollo-angular-469

Apollo Dev Tools shows one watched query and I get only one log.

@stephenlautier
Copy link
Contributor Author

@kamilkisiela in that it seems its works fine, I will try to use that API in my repo and see if it works properly or not.

@kamilkisiela
Copy link
Owner

@stephenlautier How it works? Maybe you could prepare a small reproduction of it?

@stephenlautier
Copy link
Contributor Author

yes i will try replicate what you had in mine, and ill update you

@stephenlautier
Copy link
Contributor Author

Just an update, so far I've changed my implementation to simply use the gql api you used, and did some changes to comment out some private lib we have... and its working fine now.

I can give last shot again at work exactly how it was, and maybe reinstall node modules and see if it happens agian.. but i had tested this several times and it was reproducible 100% - if i didnt had the screenshot I would think I was hallucinating =(

@intellix
Copy link
Contributor

intellix commented Mar 1, 2018

think I'm seeing something similar locally. Not sure if it's related entirely but I have the following:

private subscriptions = new Subscription();
private gamesQueryRef = this.apollo.watchQuery({ query, variables });

games$: Observable<any> = this.gamesQueryRef.valueChanges.pipe(
  map(({ data }) => data.games.edges.map(edge => edge.node)),
  shareReplay(1),
);

countdown$ = this.games$.pipe(
  map(games => new Date(games[0].scheduledAt)),
  share(),
);

ngOnInit() {
  this.subscriptions.add(this.games$.pipe(take(1)).subscribe(console.log));
  this.subscribeToMore();
}

ngOnDestroy() {
  this.subscriptions.unsubscribe();
}

subscribeToMore() {
  this.gamesQueryRef.subscribeToMore({ document, updateQuery: (prev: any, { subscriptionData }) => { ... });
}

With the shareReplay(1) and subscribeToMore, leaving the page doesn't stop the subscription so they're piling up.
With share() it does clean up but returning with instant cache causes countdown$ to miss the emit.

There's no view and the ngOnDestroy is definitely run so I'd say that apollo-angular or apollo-client isn't able to clean up the subscribeToMore for some reason. It's getting late but I'll try to create a reproduction over the weekend outside of my codebase

@ntziolis
Copy link

ntziolis commented Jul 8, 2018

Seeing the same behaviour still, anybody figured out a way to stop the leaking?

@intellix
Copy link
Contributor

intellix commented Jul 9, 2018

My issue in particular was probably shareReplay not unsubscribing: ReactiveX/rxjs#3336

@kamilkisiela
Copy link
Owner

Is this still an issue?

@stephenlautier
Copy link
Contributor Author

@kamilkisiela doest seems like it, I will close it, if anyone has the same issue will reopen if needed

@gituser3000
Copy link

gituser3000 commented Dec 17, 2021

shareReplay(1) causes leaks, but as far as i understand it should not (using destroy subjects\ async pipe) .
shareReplay({refCount: true}) fixes this, but this solution may not be appropriate

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants