index_killop_after_stepdown.js tests that an index build interrupted right as the primary steps down is not aborted, but instead completes once a new primary takes over. The sequence is:

1. Start an index build and killOp it, so the build tries to abort.
2. Force step down the primary before it can replicate an abortIndexBuild, so the abort is lost.
3. The build survives, and the new primary commits it and replicates a commitIndexBuild.
4. Assert a_1 is a ready index on the old primary.

The problem is step 4 runs too early. The test only waits with waitForIndexBuildToStop on the old primary and awaitReplication, neither of which guarantees the new primary's commitIndexBuild has been applied on the old primary. Since the test uses initiateWithDefaultElectionTimeout, the new primary takes a full election timeout to step up, so its commit lands near the end of the run and awaitReplication can return before it replicates, leaving a_1 still showing a buildUUID on the node being checked. This is why it shows up on the slow enterprise-rhel8-debug-tsan variant.

We should wait for the index to actually be ready on both nodes before asserting, for example by wrapping the assertIndexes checks in assert.soon.