@@ -361,13 +361,8 @@ export function uuidV4(): Buffer {
361361 */
362362export function maxWireVersion ( topologyOrServer ?: Connection | Topology | Server ) : number {
363363 if ( topologyOrServer ) {
364- if ( topologyOrServer . loadBalanced || topologyOrServer . serverApi ?. version ) {
365- // Since we do not have a monitor in the load balanced mode,
366- // we assume the load-balanced server is always pointed at the latest mongodb version.
367- // There is a risk that for on-prem deployments
368- // that don't upgrade immediately that this could alert to the
369- // application that a feature is available that is actually not.
370- // We also return the max supported wire version for serverAPI.
364+ if ( topologyOrServer . serverApi ?. version ) {
365+ // We return the max supported wire version for serverAPI.
371366 return MAX_SUPPORTED_WIRE_VERSION ;
372367 }
373368 if ( topologyOrServer . hello ) {
@@ -388,6 +383,17 @@ export function maxWireVersion(topologyOrServer?: Connection | Topology | Server
388383 ) {
389384 return topologyOrServer . description . maxWireVersion ;
390385 }
386+
387+ // This is the fallback case for load balanced mode. If we are building commands the
388+ // object being checked will be a connection, and we will have a hello response on
389+ // it. For other cases, such as retryable writes, the object will be a server or
390+ // topology, and there will be no hello response on those objects, so we return
391+ // the max wire version so we support retryability. Once we have a min supported
392+ // wire version of 9, then the needsRetryableWriteLabel() check can remove the
393+ // usage of passing the wire version into it.
394+ if ( topologyOrServer . loadBalanced ) {
395+ return MAX_SUPPORTED_WIRE_VERSION ;
396+ }
391397 }
392398
393399 return 0 ;
0 commit comments