Description

When a maxTimeMS query setting loosens a client-supplied maxTimeMS for a sharded aggregate (or find), mongos correctly resolves the looser effective deadline and forwards it to shards via maxTimeMSOpOnly, but leaves the original, tighter client-supplied maxTimeMS value unmodified on the wire. On the shard, service_entry_point_shard_role.cpp's generic ingress deadline logic deliberately prefers the shorter of maxTimeMS/maxTimeMSOpOnly (by design, so an internal hop's forwarded budget can never extend past what the client asked for) — so it picks the original tight value as the operation's initial deadline. Query-settings resolution (applyMaxTimeMSFromSettings) only runs later, inside the command's own invocation->run(). Generic, pre-run() steps that can block — most notably waitForReadConcern's snapshot/majority wait — therefore run against the tight, unloosened deadline, and can fail with a spurious MaxTimeMSExpired before query settings ever get a chance to apply, even though the query itself would have run comfortably within the intended looser deadline. Under normal, fast local conditions replication lag is near-zero and no wait is needed, masking the bug; it surfaces under any real replication/config lag (observed in CI under a heavy "all feature flags" sharded variant with a lagged secondary).

Fix

Have the router (cluster_aggregate.cpp, and the equivalent find-command dispatch path) overwrite the outgoing shard sub-request's generic maxTimeMS field with the fully-resolved query-settings value (when one exists) at the same point it already forwards querySettings itself, so the shard's existing generic deadline-selection logic operates on the correct value without needing any shard-side or IDL-schema changes.


Repro

Sharded cluster, tight client maxTimeMS + looser cluster-level maxTimeMS query setting on a query with readConcern: majority/snapshot semantics, secondary lagged past the tight deadline but within the loose one (e.g. via rsSyncApplyStop or a slow-secondary failpoint) — expect MaxTimeMSExpired today; expect success (or timeout only past the loose deadline) after the fix.