I discovered that the example command to find Active Indexing Operations using currentOp didn't work for me recently when I was working with 3.4.

It's a pretty helpful for finding long-running index builds in support cases, so I encourage that we keep this example, but update it to be compatible with all currently supported versions.

The difference is that the "op" value in 3.4 has changed. On a standalone or primary node it used to be "query", but in 3.4 it's changed to being "command" (which makes more sense).

It seems that the oplog docs are maintaining the appearance of being inserts to the system.indexes collection, even in 3.4. So we still need the second line so index builds can be found whilst they are being run via replication sync on secondaries. However I found that the "op" value has again changed: from "insert" to "none".

So for both of the clauses inside the outer $or operation we need $in arrays to accept two types of "op" each. New solution shown below.

db.currentOp(
     {       $or: [
         { op: { $in: [ "command", "query" ] }, "query.createIndexes": { $exists: true } }, //"op" used to be "query" in =< 3.2, is now "command" in 3.4
         { op: { $in: [ "insert", "none" ] }, ns: /\.system\.indexes\b/ }  //This is a legacy form?. It is still used in oplog so that is how it manifests on the secondary
       ]
     } )