The concurrency stepdown suites wait until after setup has been called for each workload before starting the stepdown thread because the setup methods don't run with overriden majority read/write concern. The effects of each setup are not guaranteed to be majority committed at this point though, so an immediate stepdown can still roll back some of the setup, like the creation of the TTL index in indexed_insert_ttl.js.

A fix for this would be waiting for replication on all shards and the config server before starting the stepdown thread.