Summary

This is a follow-up from DRIVERS-3239, which adds retryability to all commands if the command contains both SystemOverloadedError labels and RetryableError labels.

At the time of implementation, RetryableError and SystemOverloadedError labels are applied by the server together (there are no RetryableErrors that don't have the SystemOverloadedError).  For the client backpressure project, tying the presence of both labels together for the purposes of determining eligibility is sufficient.

The server might rely on only the `RetryableError` label in the future to indicate a command is retryable (even commands not currently retryable the retryable reads/writes specs).  We should add support for this error label to retryable reads and writes.

This was descoped from DRIVERS-3239 because:

• it is not necessary to accomplish the goal of DRIVERS-3239
• the scope of changes seemed too large to complete concurrently.  The retryable reads/writes specs need to be adjusted to allow all commands to be retryable if the new RetryableError label, tests added, etc.

This work was a part of the original Client Backpressure tech design and should be completed as a part of the backpressure follow-up work.

Motivation

Who is the affected end user?

driver engineers and users.

How does this affect the end user?

Future server commands might not be retried when they can be retried.

How likely is it that this problem or use case will occur?

right now - not possible.  in the future, uncertain.

If the problem does occur, what are the consequences and how severe are they?

Commands that could be retried and succeed will not.

Is this issue urgent?

Is this ticket required by a downstream team?

no.

Is this ticket only for tests?

no.

Acceptance Criteria

What specific requirements must be met to consider the design phase complete?