To ensure that an aggregation built around $currentOp—which is, by its very nature, a monitoring-oriented operation rather than a conventional workload query—is not inadvertently subjected to deprioritization by the execution-control mongotune policy, we must explicitly designate it as non-deprioritizable. Absent that special treatment, the policy could erroneously interpret the aggregation as an ordinary execution candidate and consequently relegate it behind other work, despite the fact that its primary function is to provide timely and indispensable observability into the system’s live state. Such a misclassification would be operationally undesirable, because it could introduce substantial and disproportionate latency into the monitoring path, causing the aggregation to take far longer than intended and, in sufficiently adverse conditions, even resulting in timeout behavior. That outcome would be especially problematic because it would impair the responsiveness of the very mechanism relied upon to inspect ongoing activity, thereby diminishing the practical usefulness of the monitoring signal at precisely the moment it may be most needed. Accordingly, in order to preserve both the reliability and the expediency of $currentOp-based introspection, the aggregation in question must be affirmatively marked as non-deprioritizable.