With the introduction of the localOps parameter, $currentOp can now return operations running locally on a mongoS. However, it is still not possible to correlate an operation on mongoS with its child operations running on the shards, without performing at least two separate aggregations and some client-side logic.

The most natural way to address this shortcoming is to allow $currentOp to run in a $lookup pipeline, subject to its normal constraints. This would allow a client to perform operations such as the following on mongoS:

mongos> adminDB.aggregate([{
    $currentOp: {
        localOps: true
    }
}, {
    $lookup: {
        from: 1,
        let: {
            "lsid": "$lsid"
        },
        pipeline: [{
            $currentOp: {}
        }, {
            $match: {
                lsid: "$$lsid"
            }
        }],
        as: shardOps
    }
}]) 

Additionally, a pipeline like the one shown above will be able to benefit from a non-correlated $lookup prefix cache between the $currentOp and $match stages. We will therefore only need to dispatch a single $currentOp to the shards, and each subsequent document in the local mongoS pipeline will simply iterate the cached results. Aside from maximising the performance of the mongoS pipeline, this will ensure that each entry in the local pipe is working with a consistent snapshot of operations on the shards.