Summary

When a query is rejected because it requires an unbounded COLLSCAN on a collection exceeding the maxEstimatedScanBytes threshold (SERVER-127688), no log line is emitted at default verbosity to indicate the rejection happened. The only trace in the mongod log is the generic user-assertion log line under the ASSERT component, which is only emitted at LOGV2_DEBUG level 1 and thus invisible unless verbosity is explicitly raised (e.g. db.setLogLevel(-5, "assert")).

This makes it very difficult for operators/TSEs to troubleshoot why a query is failing with NoQueryExecutionPlans in production, since raising verbosity is often not practical.

Suggested fix

Add an explicit LOGV2 call (default verbosity, not LOGV2_DEBUG) in the actual-rejection else branch at all three sites, mirroring the existing dry-run LOGV2 calls, e.g.:

} else {
    if (query.getExpCtx()->tryClaimMaxEstimatedScanBytesMetric()) {
        LOGV2(<new_id>,
              "Query rejected by maxEstimatedScanBytes: plan requires an unbounded COLLSCAN "
              "on a collection that exceeds the configured size threshold",
              "namespace"_attr = query.nss().toStringForErrorMsg(),
              "estimatedSize"_attr =
                  params.mainCollectionInfo.maxEstimatedScanBytesCollectionSize,
              "threshold"_attr = params.mainCollectionInfo.maxEstimatedScanBytesThreshold);
        maxEstimatedScanBytesMetrics::maxEstimatedScanRejected.increment();
    }
    return Status(
        ErrorCodes::NoQueryExecutionPlans,
        "Query rejected by maxEstimatedScanBytes: plan requires an unbounded "
        "COLLSCAN on a collection that exceeds the configured size threshold");
}

New LOGV2 IDs need to be allocated for each of the three sites. The metric increment stays guarded by tryClaimMaxEstimatedScanBytesMetric() so logging/counting still only happens once per query, consistent with existing behavior.