Some of the test pipelines in mongos_merge.js split in such a way that the shard cursors will not be exhausted by by time the merge half of the pipeline hits EOF, due to e.g. a merge-side $limit stage. When this happens, the ARM will schedule an asynchronous killCursors command to clean up the shard cursors.

However, because mongos_merge.js queries the system.profile collection immediately after running the test pipeline to confirm whether the aggregation ran as expected, on rare occasions the asynchronous killCursors command will reach the shard and be profiled while the test is scanning the profiler collection. If the capped system.profile collection is already at capacity, this will cause the first entry to be removed from the collection to make space. If the test's query has yielded at the start of the capped collection when this occurs, then it will find that the collection has rolled past its last known point when it attempts to resume iteration, and will fail with CappedPositionLost as a result.

To fix this, we should ensure that the profiler is never full by clearing it before each set of tests.