At present, a tailable awaitData cursor will scan to the end of the oplog and then, if it has not found any results which match its filter, will wait for up to 1 second (by default) for new matching events. In the case of a change stream on a sharded cluster, this can delay mongoS from returning results from other shards to the client.

We could improve the responsiveness of change streams in the following ways:

• When we reach the end of the oplog, do not wait if we have scanned past any new results; even if they do not match the filter, they will have advanced the optime and may let mongoS return results from other shards.
• While waiting, if the cursor wakes up due to new events appearing in the oplog, it will go back to sleep for the remainder of the awaitData duration if none of the new events match our filter. Instead, we should never go back to sleep once woken; even if the new events are not relevant to the stream, they will still have advanced the optime.

This will not address the problem of a completely idle shard, but will improve response times in the more common case of a stream filtering for a particular namespace on a cluster with writes occurring across multiple collections in parallel.