There is some code to lock one partition, compute everything we need from it, then release the partition lock. It all looks fine on inspection, but we've seen some suspicious build failures in one of naama.bareket@mongodb.com's patches, and an explicit test of this memory management and concurrency control would help us feel better.

Broadly, the test should have:

• Many threads doing queries
  • Some repeat queries that would modify existing entries in the query stats store (incrementing metrics and changing timestamps)
  • Some novel queries adding to the query stats store. Ideally enough that by the end of the workload we see some eviction logic kicking in (can be confirmed in serverStatus.metrics.queryStats output)
  • Some finds, some aggregates, to make sure the two codepaths are both handled correctly
• At least one thread or maybe a couple doing $queryStats, some with "transformIdentifiers", some without.
  • It would be good to have a very small batch size like 1 or 2 to ensure that the getMore loop doesn't introduce bugs.