Polling stops on error

I’m currently trying to set up a polling process to check the status of a long operation, here’s some example code:

const waitForCompletionQuery = gql`
query WaitForCloneCompletion {
  operationStatus {
    isCompleted
  }
}
`;

async function waitForCompletion(apolloClient) {
  const query = apolloClient.watchQuery({
    query: waitForCompletionQuery,
    forceFetch: true,
    pollInterval: 5000
  });
  let subscription;
  try {
    await new Promise((resolve, reject) => {
      const observer = {
        error: (err) => {
          if (isOKError(err)) {
            // Alert the user to the error and keep trying
            showErrorToast(err);
          } else {
            reject(err);
          }
        },
        next: (result) => {
          if (result.loading) return;
          const status = result.data.operationStatus;
          if (status.isCompleted) {
            resolve();
          }
        }
      };
      subscription = query.subscribe(observer);
    });
  } finally {
    if (subscription) {
      subscription.unsubscribe();
    }
  }
}

Some errors would be considered “OK” (like network errors, which probably makes this at least somewhat related to https://github.com/apollostack/apollo-client/issues/270) - while I need to make them known to the user, I should keep polling. Others indicate an operation failure and I should stop polling because it’s not going to change.

I would expect the above code to behave in that way, returning a promise that resolves on the first isCompleted value or rejects on the first non-OK error, but what actually appears to happen is that the polling just stops after the first error, and won’t start back up even if I explicitly call query.startPolling(5000) or subscription = query.subscribe(observer) after showErrorToast().

Is this user error or something odd in Apollo?

[daniman]

@helfer can we bump this? 😃

For transient errors that are acceptable while polling, like network errors, it’d be nice if AC continued to poll and handled those errors elegantly. For cases where you’d want to display a network error toast or something, we could expose the state/error on the network status that indicates that the query is not actively polling successfully.

[dallonf]

My expectation of default behavior is that polling would go on forever until explicitly stopped (which in most higher-level usage, happens when the subscribed component unmounts), so I would also expect the error callback to be called for each new error (although it would also make some sense if it only was called for different errors, like next is only called for new data).

But if the behavior of automatically stopping a poll on error was considered expected and documented, then the ability to re-subscribe would definitely unblock my use case.