Use Case

As a driver user
I want non-experimental features to be correctly documented
So that I can be sure I'm not relying on non-fixed API's

User Experience

• As a result of NODE-7396, some entities have been found to no longer belong in the experimental category and their @experimental tag should be removed.
  Check the full experimental entity list in this document (subject to update after NODE-7396 concludes). Some examples:

• • ClientEncryptionRewrapManyDataKeyProviderOptions – source
  • ClientEncryptionRewrapManyDataKeyResult – source
    • Note: ClientEncryptionRewrapManyDataKeyResult is exported and tagged @experimental but is not actually used by rewrapManyDataKey() – the method returns an inline Promise< { bulkWriteResult?: BulkWriteResult }> instead of the named type. Either wire the method's return type to ClientEncryptionRewrapManyDataKeyResult or reconcile the exported interface.

Dependencies

• Relies on NODE-7396

Risks/Unknowns

• None

Acceptance Criteria

Implementation Requirements

• All the entities marked for removal in the spreadsheet have had their '@experimental' tag removed (Node driver experimental features verification sheet):
  • DropCollectionOptions.encryptedFields
  • CreateCollectionOptions.encryptedFields
  • ClientEncryptionCreateDataKeyProviderOptions.keyMaterial
  • ClientEncryptionRewrapManyDataKeyProviderOptions
  • ClientEncryptionRewrapManyDataKeyResult
  • ClientEncryptionEncryptOptions.textOptions
  • TextQueryOptions
• These will need to go in as a feat / minor release

Testing Requirements

• ClientEncryptionRewrapManyDataKeyResult used as the return type from rewrapManyDataKey, should have type tests.

Documentation Requirements

• PR should include a list of the features that were offboarded, and a mismatch matrix between what's noted in the spreadsheet.

Follow Up Requirements

• None