Summary

When a $searchMeta aggregation runs through mongos, the query stats store key records the expanded internal form of the stage (mongotQuery, metadataMergeProtocolVersion, limit, mergingPipeline, ...). That key cannot be re-parsed when $queryStats is read: the shape serializer writes limit as a representative int32 (document_source_internal_search_mongot_remote.cpp, serializeWithoutMergePipeline), while internal_search_mongot_remote_spec.idl declares the field as strict long, so re-parse fails with TypeMismatch: BSON field '$searchMeta.limit' is the wrong type 'int', expected type 'long'.

On release builds, these errors are silenty skipped and these queries are missing from query stats output. On debug builds (or with internalQueryStatsErrorsAreCommandFatal), the $queryStats read then fails with QueryStatsFailedToRecord — and keeps failing, since the poisoned key stays in the store.

It seems like this issue is probably long-standing -- I can't pinpoint anything that's changed recently to cause this.

Repro

On any mongos-fronted cluster (collection does not need to be sharded), debug build:

db.adminCommand\({setParameter: 1, internalQueryStatsSampleRate: 1}\);
db.c.insertOne\({}\);
db.runCommand\({aggregate: "c", pipeline: \[{$searchMeta: {index: "x", text: {query: "a", path: "b"}}}\], cursor: {}}\);
db.getSiblingDB\("admin"\).aggregate\(\[{$queryStats: {}}\]\);  // fails: QueryStatsFailedToRecord \(435\)

Or run jstests/with_mongot/e2e/search/search_query_stats.js in any mongot_e2e_* suite with a mongos after removing its assumes_against_mongod_not_mongos tag (added by SERVER-131029 to work around this bug; remove the tag as part of this fix).

Possible fixes

• Make the representative value round-trip: serialize limit as a long in serializeWithoutMergePipeline (an identical serializeLiteral((long long)...getLimit()) pattern exists in the explain serialization path in the same file — check it too), or
• Relax the IDL field to a lenient numeric type (safeInt64).

Also worth considering whether recording the planShardedSearch-expanded internal form (rather than the user-facing $searchMeta spec) is the intended query shape on mongos at all — on a standalone mongod the same query records [{$searchMeta: "?object"}], so shapes for the same user query differ by topology.