Summary

Include version in errors produced by mongocryptd

Motivation

MONGOCRYPT-812 prefixes errors with [crypt_shared <version>]. Example:

[crypt_shared 8.0.0] failed: BSON field 'insert.bad_field' is an unknown field. [Error 2, code 40415] 

This ticket proposes similarly adding the version in errors from mongocryptd. Drivers use a MongoClient to run commands directly to mongocryptd, so this error information cannot be added in libmongocrypt.

Including the version may give users a hint that their crypt_shared / mongocryptd component is too old.

Who is the affected end user?

Users of CSFLE / QE using mongocryptd.

How does this affect the end user?

crypt_shared / mongocrypd produces an error on unrecognized MQL. A user connected to a new mongod / mongos server may expect new MQL to work, but get an error from crypt_shared / mongocrypd failing to process the command.

Example scenario (see mongocryptd-too-old.py for a working example):

• Use mongod 7.0 (supports $median)
• Use mongocryptd 6.0 (does not support $median)
• Gets error: Invalid $project :: caused by :: Unknown expression $median

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

Certain. Quoting conversation with erwin.pe@mongodb.com:

during a sync with product, the topic of programmatically ensuring that the mongo_crypt_v1.so and mongocryptd versions are compatible with the version of mongod/s that the client is connected to came up for discussion. The main motivation is that there have been several instances where people got tripped up on having a mongocryptd/shared version that don't support the newer query expressions, but got no clear indication of the root cause of the issue.

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

Confusion. Minor?

Is this issue urgent?

No.

Is this ticket required by a downstream team?

No?

Is this ticket only for tests?

No.

Acceptance Criteria

• A user observing an error caused by mongocryptd can inspect the error for the mongocryptd version.