Each SBE plan cache key incorporates a Timestamp defined as the commit timestamp of the most recently constructed index visible to the reader. This is necessary to deal with some subtle concurrency problems for the SBE plan cache which I won't explain here, but you can see this comment or SERVER-65083 for details.

The code which calculates the SBE plan cache key Timestamp has a data race detected by TSAN. It traverses all indexes, both ready ones and in-progress index builds, and calls getMinimumVisibleSnapshot() on each IndexCatalogEntry. In the case of lock-free reads, this can race with another thread that is setting the value of the minimum visible snapshot on the same object.

The data race is possible due to a flaw in the catalog's implementation of lock-free reads. As noted in SERVER-70607, the IndexCatalogEntry should follow copy-on-write semantics for the commit timestamp. Until SERVER-70607 is fixed, we can work around the problem. gregory.noma@mongodb.com suggested a workaround in which the SBE plan cache's timestamp calculation simply never considers in-progress index builds. The task for this ticket is to implement the workaround.