When constructing a CancelableOperationContext, it will create a future in order to kill the associated OperationContext if the cancellation token is canceled. That future is not released in the destructor, but rather, it will stay associated to the cancellation source.

This is not problematic if the cancellation source is short-lived, for example, linked to a specific operation. However, in some cases, a cancellation source is reused across operations. An example of this is the MigrationDestinationManager: It is a singleton which will create a single cancellation source which is reused across multiple all chunk migrations, and is only canceled on stepdown.

In the case of the recipient of a chunk migration, this turns into a fast memory leak: The MigrationDestinationManager will create a SessionCatalogMigrationDestination in order to migrate oplog entries associated to sessions. Every iteration of the main loop will create a CancelableOperrationContext, whose cancellation source is linked to the MigrationDestinationManager, and once the migration reaches the ReadyToCommit state, the main loop will spin without throttling, rapidly building memory use.