The noPassthrough test plan_cache_index_create.js intermittently fails on the secondary read path (second runTest invocation, readDB=secondaryDB) with:

uncaught exception: Error: expected 0 to equal 1 : [ ] :
getIndexNameForCachedPlan@jstests/noPassthrough/query/plan_cache/plan_cache_index_create.js:27
runTest@jstests/noPassthrough/query/plan_cache/plan_cache_index_create.js:114
@jstests/noPassthrough/query/plan_cache/plan_cache_index_create.js:201

The test expects exactly one plan-cache entry after running a find while a background index build is in progress, but observes zero.

Root Cause. The plan cache for a collection is invalidated on each catalog change. On the secondary, an in-progress index build performs this invalidation across two distinct moments:

registering – the build first becomes visible in currentOp.
starting/initialized – the build completes its setup (durable catalog change), which invalidates the plan cache a second time.
IndexBuildTest.waitForIndexBuildToStart() returns as soon as the build is visible (moment 1), before setup (moment 2) is done. The test then:
passes assertDoesNotHaveCachedPlan (cache empty),
runs a find that creates a plan-cache entry,
has that entry wiped by the build's setup catalog change,
lists the cache and sees 0 entries → assertion fails.
The hangAfterStartingIndexBuild failpoint only stalls the build later, in the collection-scan phase (multi_index_block.cpp), after the invalidating setup, so nothing holds the build still during the vulnerable window. The timing was exposed/worsened by SERVER-111304 (apply PDIB on secondaries without a builder thread).