Origin

Adjacent-risk hunt from the BF-46466 postmortem. Confidence: low — likely a FALSE POSITIVE in the mock domain; file as cleanup, not a bug. Related: [BF-46466].

Summary

executor::ProxyingExecutor::sleepFor (src/mongo/executor/async_rpc.h:191-197) computes its deadline with Date_t::now() (real wall clock) and then chooses between netBaton->waitUntil(deadline, token) (baton/precise-clock timer) and _executor->sleepFor(duration, token) (network-clock timer) based on whether _baton->networking() is non-null. The two branches therefore evaluate the deadline against a different clock than the one that drives the timer — the same precise-vs-network assumption that BF-46466's harness tripped on, but here in production code.

Important caveat from the postmortem review: in the mock domain this is not reachable as a bug. Baton::networking() returns nullptr by default (src/mongo/db/baton.h:76); DefaultBaton does not override it; SubBaton::networking() forwards to the parent (baton.cpp:65-66). So with any opCtx DefaultBaton, sleepFor always takes the correct _executor->sleepFor(duration) fallback, whose timer is on the executor/network (mock) clock. The netBaton->waitUntil branch is reachable only with a real transport (AsioNetworkingBaton), where the wall clock is the correct clock. A confirm test that sets options->baton on a mock retry-delay test would take the fallback branch and not hang.

This is a documentation/consistency nit, not a dormant landmine. File it as cleanup, not a bug guard.

Scope

src/mongo/executor/async_rpc.h:191-197 (ProxyingExecutor::sleepFor), and the related AsyncRequestsSender (src/mongo/s/async_requests_sender.cpp:517-527) whose deadline is evaluated on the network/executor clock but whose timer is stored on the SubBaton/precise clock — the same cross-clock assumption, only accidentally consistent inside the mock (both clocks are one global ClockSourceMockImpl).

Acceptance Criteria

• ProxyingExecutor::sleepFor computes its deadline from the clock that actually drives the selected timer branch (or both branches route through a documented helper that names the clock choice).
• The AsyncRequestsSender deadline-vs-timer-clock choice is documented (or routed through the same helper).
• No new test that asserts a hang on the netBaton branch under mock clocks (it cannot hang there).

Verification (confirm/deny)

No confirm test is appropriate. The branch is guarded by the absence of a mock networking() implementation. A static note replaces a test: "the netBaton->waitUntil branch is unreachable with any mock-driven baton; the wall-clock deadline is correct for the real-transport (AsioNetworkingBaton) path where it is reachable."

Investigation

• Confirm Baton::networking() remains nullptr-default and that no mock baton overrides it.
• Decide whether changing the deadline source could break the real-transport (AsioNetworkingBaton) contract that non-mock callers depend on (postmortem Open Question 6).

{info:title=Team note}Filed to Query Integration as a placeholder owner per the postmortem; the owning team is Executor. Please reassign Assigned Teams on triage.{info}