Background

By retryable reads we refer to the ability of MongoDB drivers to automatically retry idempotent commands when the server returns a retryable error. The list of retryable commands and retryable errors is defined in the retryable reads driver specs.

Today, each driver implements its own logic to decide whether it is safe to retry a failed command.

Problem

This approach does not scale well. Whenever we need to introduce any of the following:

• a new retryable command
• a new retryable error code
• a new non-retryable aggregation stage (e.g. $out)

we must update the code of all 13 officially supported drivers to account for these changes. This increases maintenance cost and the risk of inconsistent behavior across drivers.

Proposal

Move the retryability decision into the server. The server should determine whether all conditions for safely retrying a failed command are met, and communicate this to the driver by attaching a special RetryableError label to the command response.

When a driver sees this label, it can safely and unconditionally retry the operation, without re-implementing the detailed retryability logic in each driver.