It is possible that a client receives multiple isMaster responses in quick succession when using the streamable protocol. The task executor layer keeps track of tasks in a queue and holds an iterator pointing to the task. If multiple responses are received super quickly (within about a ms of one another), the later responses can overwrite the iterator value for a task when adding the new task to the queue if the previous responses have not been run yet. This means we would not erase one or more tasks from the task executor's queue because we lose track of the iterator and can hang at shutdown. We can fix this by keeping track of what we expect the iterator to be and compare when running the callback and removing the task, use the appropriate iterator.