When mongoc_topology_select_server_id() decides to scan the topology in single-threaded mode, it calculates "how soon are we allowed to scan?" by adding minHeartbeatFrequencyMS to the last scan time. This calculation occurs irrespective of whether any nodes will actually be scanned. For example, previous connection failures may result in all nodes being excluded from this scan due to cooldownMS. Ideally, the loop should check if there will be nodes to scan before a possible sleep for minHeartbeatFrequencyMS or call to _mongoc_topology_do_blocking_scan().

Consider the case in mongodb/mongo-php-driver#592. A PHP worker with a newly created libmongoc client attempts to connect to a closed port on an accessible host, which fails immediately and leaves the node in the "Unknown" state. A subsequent requests to that worker will re-use the persisted libmongoc client and block until minHeartbeatFrequencyMS has elapsed since the previous request's failure. In a high-concurrency environment, this means that each request will block for approximately minHeartbeatFrequencyMS instead of failing early, despite any attempts to tweak serverSelectionTimeoutMS (note: connection/socket timeouts aren't relevant here).

The spec's pseudo-code for Scanning Order does not address minHeartbeatFrequencyMS; however, it does refer to aborting early if there would be no nodes to scan, as is the case here.

On a related note, there is logic to abort early with a server selection failure if the calculated time would exceed our server selection timeout, however, this logic does not apply in serverSelectionTryOnce mode and it would not affect the scenario described in the linked PHP ticket.