When FLE is used, the server-side `count` command rewrites the request object here: https://github.com/10gen/mongo/blob/8e1bf8565ef06ec247392e262ebcdc0202775401/src/mongo/db/commands/query_cmd/count_cmd.cpp#L339

Before it rewrites the request, it logs a message (with debug severity) containing the full request: https://github.com/10gen/mongo/blob/8e1bf8565ef06ec247392e262ebcdc0202775401/src/mongo/db/commands/query_cmd/count_cmd.cpp#L337

This does not look ideal, because it may potentially leak lookup values into the logfile.

Something similar happens for the server-side `find` command here: https://github.com/10gen/mongo/blob/8e1bf8565ef06ec247392e262ebcdc0202775401/src/mongo/db/commands/query_cmd/find_cmd.cpp#L1044

More commands may be affected by this (currently unclear).

It looks like the log messages were added originally so that the combination of FLE & mirrored reads could be tested more easily from the outside. Currently there is a test that depends on the log messages being written: https://github.com/10gen/mongo-enterprise-modules/blob/791e8805f9fd260852a742e7e0a91d8a60cd606d/jstests/no_passthrough/fle2_mirror_reads.js#L8

It would be better to not log the requests for `count` and `find` commands at all, as they may potentially leak sensitive lookup values or context. If we remove the logging though, we need to find another way to test that the mirrored reads have happened.