Having multiple polling queries on the same QueryManager causes setInterval leak

I discovered this one via a React component (with Apollo connect container) that had multiple polling queries. Each time I unmounted & mounted the component, I would get a polling leak, as evidenced by increasingly frequent HTTP requests to my /graphql endpoint.

I put some console logging in this zone https://github.com/apollostack/apollo-client/blob/master/src/QueryManager.ts#L426-L455, like this:

  private startQuery(options: WatchQueryOptions, listener: QueryListener) {
    const queryId = this.generateQueryId();
    this.queryListeners[queryId] = listener;
    this.fetchQuery(queryId, options);
    if (options.pollInterval) {
      this.pollingTimer = setInterval(() => {
        const pollingOptions = assign({}, options) as WatchQueryOptions;
        // subsequent fetches from polling always reqeust new data
        pollingOptions.forceFetch = true;
        this.fetchQuery(queryId, pollingOptions);
      }, options.pollInterval);
+++   console.log('starting timer', this.pollingTimer)
    }
    return queryId;
  }

  private stopQuery(queryId: string) {
    // XXX in the future if we should cancel the request
    // so that it never tries to return data
    delete this.queryListeners[queryId];

    // if we have a polling interval running, stop it
    if (this.pollingTimer) {
+++   console.log('stopping timer', this.pollingTimer)
      clearInterval(this.pollingTimer);
    }

    this.store.dispatch({
      type: 'APOLLO_QUERY_STOP',
      queryId,
    });
  }

I mounted & unmounted the component twice, and the component sets up 3 polling queries on every mount. Here’s the result:

As you can see it looks like we have lost (overwritten?) our references to timers 94, 128, 146, & 147.

[Poincare]

I think that issue is currently mentioned in the code as something to fix. It seems the polling structure requires some pretty significant changes so that (1) polling doesn’t leak (2) we can keep track of the queries that have been sent to the server (probably by query id) and don’t re-fire the same query again.

I think fixing this issue is actually pretty intimately connected to the batching over HTTP since I’ve been building a tick-based scheduler-like system for that anyway. Hopefully, that will make it easier to resolve this issue and others that involve the current polling system.

[Poincare]

Sure, I’ll look into this in detail tomorrow and hopefully make some headway on some kind of fix.