Background

When a new field is added to a command reply via generic_argument.idl or a dedicated reply IDL struct, an older mongos (or shard acting as sub-router) parses the reply from a newer binary using a strict IDL struct (strict: true), and rejects the unknown field with IDLUnknownField. This cannot be gated behind FCV because FCV only tracks major.minor, not patch versions.

This issue was surfaced in SERVER-128128 and discussed in #server-dev-platform. The consensus from @mathias, @mark, and others:

• strict: true makes sense for requests (to catch typos and enforce required semantics), but not for replies
• Replies are not user-typed; an older binary encountering an unknown reply field should silently ignore it, not crash
• We should disallow strict: true on reply structs in IDL

Proposed Work

1. Audit all IDL reply structs (reply_type: and structs used as reply types) that currently set strict: true.
2. Add an IDL linting rule or compile-time check that rejects strict: true on any struct declared as or used as a reply type.
3. Flip existing offending reply structs to strict: false.

Why This Matters

Until this is enforced, adding any new reply field and backporting it is either impossible or requires workarounds such as piggybacking on an existing object_owned generic field. This blocks teams from safely evolving the wire protocol across patch boundaries.