In SERVER-54937 we added an _assertNotInvalidated call in the AsyncResultsMerger to check whether a change stream cursor has been invalidated. This is called right before we schedule further getMores to the shards. We moved it here from AsyncResultsMerger::nextEvent() in SERVER-56871 since otherwise, a stream which does not return any events will never actually be invalidated.

However, we also call into this code path from the callback function that we assign to an asynchronous getMore, which are scheduled automatically as long as a valid opCtx exists and the previous batch received from the shard was empty. At a glance, it looks conceivable that this callback may throw while an exception thrown by another callback function or via this call in the BlockingResultsMerger is already active.

We should investigate whether it is possible to crash the process by inducing this scenario. If so, we'll need to rework our approach.