Bulk insertions on a node are divided into smaller sub-batches, each containing up to 64 documents by default (as specified by internalInsertMaxBatchSize). Non-transactional bulk insertions don't atomically synchronize with DDL operations; instead, they only synchronize at the individual sub-batch level. If a rename operation occurs between two sub-batch insertions, the second batch will recreate the old namespace and insert data there.

This can result in two collections containing partial data instead of a single collection with all the data, causing the post insertion check to fail.

This issue was previously addressed by limiting the number of documents inserted in the test to fewer than 64 (as per SERVER-88111), preventing the need for multiple insertions.

However, with the implementation of SERVER-95138, the batch size parameter became user-configurable. The config fuzzer can now set it to a random value, potentially lower than 64, which reintroduces the original problem.

The goal of the ticket is to re-think to the original solution found in SERVER-88111 and think of a way to prevent the problem when the internalInsertMaxBatchSize is lower then 60 (current batch insertion for the test).