The server selection spec mandates operationCount-based selection within the latency window for multi-threaded drivers (see "operationCount" and "operationCount-based selection within the latency window (multi-threaded or async)" in source/server-selection/server-selection.md): pick two random servers from the latency window and select the one with the lower number of in-flight operations.

The Ruby driver does not implement this. Selection within the latency window is a plain shuffle-and-pick-first (lib/mongo/server_selector/base.rb, suitable_server / near_servers), and no operationCount tracking exists anywhere in lib/. RUBY-2799 only tracked the flakiness of the corresponding prose test; the algorithm itself was never implemented.

Why this matters: the spec's rationale for this algorithm is routing operations away from servers as they become less responsive. This is exactly the failure mode of the recent incident (RUBY-3804, RUBY-3890, HELP-92085): a node with a failed EBS volume kept answering hello (in-memory) while queries hung, so SDAM kept it selectable and the driver kept routing reads to it. With operationCount-based selection, hung or slow operations keep the sick node's in-flight count elevated, and every latency-window (read) selection avoids it - with no configuration and no spec change required. It works both when the node still accepts new connections and when it does not, and it does not depend on CSOT being configured.

Scope:

• Track per-server operation count: increment when a server is selected for an operation, decrement when the operation completes (per the spec, decrementing must not wake threads waiting for topology updates).
• In latency-window selection, choose two distinct random servers and select the one with the lower operationCount; tie-break arbitrarily.
• Add the "operationCount-based selection within latency window" prose test from the server selection spec tests.

This does not affect single-candidate selections (primary read preference, writes).