Use Case

As a node driver developer
I want the base MongoError class to have no specialized error logic
So that it's easier to trace the source of particular error attributes

This will help us track where the code property is actually being parsed in; in general, numeric codes should only be the ones coming from the server error documents

Dependencies

• NODE-3337 should be done first because there is some logic that expects the code property to exist on the MongoError class

Unknowns

• questions that need to be answered to determine implementation

Acceptance Criteria

• Remove "code" property from the general MongoError class, moving it to more specific classes as needed

Implementation Requirements

• The following systematic approach is recommended, checking to make sure no tests are broken at each stage:
  1. Locally, remove the code property from the MongoError class
  2. Run the typescript compiler via `npm run build:dts` to identify all places where error.code is accessed
  3. Put the property back into the MongoError class
  4. Iterate through each place where error.code is accessed:
     1. Check whether adding an extra instanceof MongoServerError check to the chain breaks any tests
     2. If tests are broken, figure out which errors this check is filtering out that should not be filtered out, and the correct way to address that
  5. Once all places of code property access are fixed, remove it from the MongoError class
  6. Finally, remove any unneeded typeof error.code === 'number' checks

Testing Requirements

• All tests should still pass, some modifications to unit tests may be needed

Documentation Requirements

• None

Follow Up Requirements

• None