SERVER-78154 added code in the fsync command to detect and fail in the presence of concurrent DDL operations. The way it is currently working is by querying the config.system.sharding_ddl_coordinators collection and checking for documents present there, however, the test is not sharding the collection that will be refined, and considering SERVER-76486 will change refine collection shard key flow, the following scenario becomes possible:
1. A refineCollectionShardKey command is sent The service is created, but because of SERVER-76486 the check of the collection (it must be sharded in order to continue) is done before the first store in disk.
2. The refineCollectionShardKey fails but then stops in the failpoint
3. The fsync command runs, checks for the coordinator document, but doesn't find anything because the DDL haven't registered the coordinator document yet
This scenario goes against the initial intention of the test, so we should shard the collection at the beginning of the test.
- is caused by
-
SERVER-78154 Detect on-going DDL operations in fsync with lock command
- Closed
- is depended on by
-
SERVER-76486 Make RefineShardKey coordinator authoritative on shards
- Closed