Summary

The Client-Side Encryption "Explicit Encryption" prose test Case 2: can insert encrypted indexed and find with non-zero contention fails against the latest MongoDB server. The test's Test Setup creates the db.explicit_encryption collection from encryptedFields.json, which configures the encryptedIndexed field with contention: 0, but Case 2 inserts and queries with contentionFactor: 10. The server now rejects this mismatch SERVER-91887.

Background

The Test Setup shared by all Explicit Encryption cases loads encryptedFields.json and creates db.explicit_encryption with it. The encryptedIndexed field is configured with:

"queries": {
   "queryType": "equality",
   "contention": { "$numberLong": "0" }
}

• Case 1 encrypts with contentionFactor: 0 throughout — consistent with the collection configuration.
• Case 2 inserts 10 documents with contentionFactor: 10, then queries with contentionFactor: 0 and contentionFactor: 10 — a mismatch against the collection's configured contention of 0.

This mismatch has always existed in the prose test but was silently accepted by the server until recently.

On the latest server, Case 2's first insert (whose randomly chosen contention value is non-zero) is rejected with:

MongoCommandException: Command execution failed on MongoDB server with error
9188700 (Location9188700): 'contentionFactor 1 in payload for field
'encryptedIndexed' exceeds collection's configured contention 0'

Stable/released servers predate this validation, so the test only fails on the latest (nightly / non-standard-latest) server.

Proposed change

Update the Explicit Encryption prose test so Case 2 runs against a collection whose configured contention matches the contentionFactor: 10 it uses. Concretely: in Case 2, drop and recreate db.explicit_encryption with a copy of encryptedFields whose encryptedIndexed field sets contention: 10, before the insert loop. Case 1 is unaffected and continues to use the shared contention: 0 collection.

This keeps the test's intent (non-zero contention: a contentionFactor: 0 query returns a subset; a contentionFactor: 10 query returns all 10) while satisfying the new server validation.

Motivation

Who is the affected end user?

Implementators

How does this affect the end user?

n/a

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

All drivers implement this prose test and are affected on the latest server. Each driver should pick up the spec change and update its Case 2 implementation.

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

CI goes red

Is this issue urgent?

Is this ticket required by a downstream team?

No

Is this ticket only for tests?

Yes - its an update to a single prose test.

Acceptance Criteria

Updated test logic for Case 2