mongodb/node-mongodb-native · error · MongoUnexpectedServerResponseError

Selected server does not support retryable writes

Error message

Selected server does not support retryable writes

What it means

During retry inside executeOperationWithRetries (src/operations/execute_operation.ts:360), after re-selecting a server, the driver checks supportsRetryableWrites(server). If the new server does not support retryable writes and the error is not a SystemOverloadedError, a MongoUnexpectedServerResponseError is thrown. This typically happens when a failover lands the operation on a standalone or otherwise incompatible server.

Source

Thrown at src/operations/execute_operation.ts:360

        (operationError.hasErrorLabel(MongoErrorLabel.SystemOverloadedError) &&
          topology.s.options.enableOverloadRetargeting)
      ) {
        deprioritizedServers.add(server.description);
      }

      server = await topology.selectServer(selector, {
        session,
        operationName: operation.commandName,
        deprioritizedServers,
        signal: operation.options.signal
      });

      if (
        hasWriteAspect &&
        !supportsRetryableWrites(server) &&
        !operationError.hasErrorLabel(MongoErrorLabel.SystemOverloadedError)
      ) {
        throw new MongoUnexpectedServerResponseError(
          'Selected server does not support retryable writes'
        );
      }

      // Batched operations must reset the batch before retry,
      // otherwise building a command will build the _next_ batch, not the current batch.
      if (operation.hasAspect(Aspect.COMMAND_BATCHING)) {
        operation.resetBatch();
      }
    }
  }

  throw (
    error ??
    new MongoRuntimeError(
      'Should never happen: operation execution loop terminated but no error was recorded.'
    )
  );

View on GitHub (pinned to 3366c21a63)

Solutions

1. Verify the deployment topology is a healthy replica set or sharded cluster (not standalone) when using retryable writes.
2. If the deployment genuinely cannot support retryable writes, set retryWrites=false.
3. Check cluster health and re-run; transient failovers may resolve on the next attempt.
4. Inspect server hello output to confirm `retryableWrite` capability on all members.

Example fix

// before
const client = new MongoClient('mongodb://localhost'); // standalone, retryWrites defaults true
await coll.updateOne({}, { $set: { a: 1 } }); // after a failover → throws

// after
const client = new MongoClient('mongodb://localhost/?retryWrites=false');
// or deploy as a replica set so all members support retryable writes

// Confirm all cluster members report retryable write support
const hello = await client.db().admin().command({ hello: 1 });
if (!hello.retryableWrite) {
  // set retryWrites=false or fix topology
}

try {
  await collection.updateOne(filter, update);
} catch (err) {
  if (err instanceof MongoUnexpectedServerResponseError && /retryable writes/.test(err.message)) {
    // wait for topology to stabilize, then retry once; otherwise disable retryWrites
  } else throw err;
}

When it happens

Trigger: A retryable write fails on one server, the driver re-selects, and the newly selected server (e.g. a standalone promoted during a topology change, or a server that lost its replica-set membership) does not support retryable writes.

Common situations: Replica set converting to standalone, an election that leaves a non-retryable-capable server selected, or a topology misconfiguration in a sharded cluster where a mongos does not report retryable-writes support.

Related errors

• Driver attempted to initialize in load balancing mode, but t
• Current topology does not support sessions
• SRV URI does not support directConnection
• Cannot use srvMaxHosts option with replicaSet
• directConnection option requires exactly one host

AI-assisted analysis of mongodb/node-mongodb-native@3366c21a63 (2026-08-04). Data as JSON: /data/errors/05b6b6e1ca07e0a8.json. Report an issue: GitHub.