Use Case

The reauthentication section of the auth spec says:

Any errors that could not be recovered from during reauthentication, or that were encountered during the subsequent re-attempt of the operation MUST be raised to the user.

We currently do the opposite: if reauthentication fails, we instead squash errors from reauthentication and throw the original error.

This can make it challenging to debug why an application is failing with 391 errors (ex: https://jira.mongodb.org/browse/HELP-83883).

User Experience

• Users should have as much information as possible about why their operation failed, when the connection needed to reauthenticate.

Dependencies

• n/a

Risks/Unknowns

• Can we somehow throw an AggregateError that contains all the errors the driver encountered over the course of the operation?

Acceptance Criteria

Implementation Requirements

• At a minimum, throw the error encountered during reauthentication instead of the operation's error. If possible, include both errors (maybe in a special subclass of MongoError that can contain multiple causes).

Testing Requirements

• unit test, spec test sync, etc

Documentation Requirements

• DOCSP ticket, API docs, etc

Follow Up Requirements

• additional tickets to file, required releases, etc
• if node behavior differs/will differ from other drivers, confirm with dbx devs what standard to aim for and what plan, if any, exists to reconcile the diverging behavior moving forward