Summary

Introduce a server-side configuration option that enforces a minimum timeout for pre-auth streamable hello commands.

Today, streamable hello can be abused when a client supplies a very small maxAwaitTimeMS value, especially 0, causing the server to wake up and re-arm the stream immediately rather than spending most of its time waiting for either a topology change or timeout. In the worst case, this allows an unauthenticated client to create a high-rate server-side loop over many connections.

The proposed mitigation is to add a configuration knob that defines a floor for the effective timeout used by streamable hello. If the configured floor is T seconds, then the steady-state timeout-driven wakeup rate is bounded to roughly MaxConnections / T executions per second.

This should preserve the main benefit of awaitable / streamable hello: topology-change detection latency should not be materially affected, because awaitable hello returns as soon as there is a topology change; the timeout only defines the maximum wait before returning a response.

Drivers are specified to set maxAwaitTimeMS = heartbeatFrequencyMS, and multi-threaded / asynchronous drivers default heartbeatFrequencyMS to 10 seconds today, so the natural default for this new configuration should align with that existing driver behavior rather than introducing a new value.

Proposed behavior

Add a server configuration option (e.g. minWaitForStreamingHelloMillis) for the minimum timeout applied to pre-auth streamable hello – If a client supplies maxAwaitTimeMS below the configured minimum, the server should log the incident (maximum of one log at INFO level every 5 seconds, and the remaining at D3). Depending on the value for another server parameter (settable both at startup and runtime), the server will decide to either fail the corresponding operation or use the minimum of provided value and minWaitForStreamingHelloMillis for its timeout. The new server parameter can be called abortStreamingHelloWithSmallTimeout, defaulting to false.

Default the new option to the current driver behavior for streaming monitoring, i.e. 10 seconds for multi-threaded / asynchronous drivers.

Apply the change specifically to the streamable / exhaust monitoring path, where the hot-loop behavior is relevant.

Preserve existing behavior where topology changes wake the waiter immediately regardless of timeout.

Trade-offs / notes

This mitigation does not materially affect topology-change detection latency, but it can reduce the frequency of timeout-based liveness observations if drivers rely on that path.

This is primarily a CPU / wakeup-rate mitigation, not a fix for all pre-auth resource classes.

This should be framed as a bounded mitigation for the timeout-driven hot-loop case, especially maxAwaitTimeMS: 0