-
Type: Bug
-
Resolution: Duplicate
-
Priority: Minor - P4
-
None
-
Affects Version/s: 3.0.12
-
Component/s: Diagnostics
-
None
-
ALL
Emulating the db.currentOp() shell method on older MongoDB versions (without the currentOp command) requires a query to the admin database's $cmd.sys.inprog collection. I encountered the following assertion failure when attempting to query the current op from the PHPC driver:
AssertionException handling request, closing client connection: 16810 bad query: BadValue unknown top level operator: $query
From the driver's perspective, the socket is closed and we time out while attempting to read a response.
The assertion is no doubt due to logic in the PHPC driver that always includes the filter under a top-level $query field, even if the query contains no other modifiers necessitating so (e.g. $orderby, modifiers). While this is certainly something we can fix in PHPC, I wonder if the the server should still relax its assertion here.
I've linked this to SERVER-17951, where the server was rejecting similar queries due to a top-level $readPreference field. If this is deemed worthy of a fix, you may want to also investigate the killOp and fsyncUnlock operations, which were also addressed in SERVER-17951.
- duplicates
-
SERVER-6767 Interpret $query as special so you can copy profiler/logged queries into shell
- Closed
- is related to
-
SERVER-17951 db.currentOp() fails with read preference set
- Closed
- related to
-
PHPC-705 Do not unnecessarily wrap filters in $query
- Closed