There have been multiple BFs for the monotonicity tests where the analyzeShardKey command incorrectly reports that a shard key is not monotonic although it is. Simply increasing the number of documents (i.e. data points for the correlation coefficient calculation) like in SERVER-71361 does not fully solve the issue since the OplogApplier is able to batch a lot of inserts together (replWriterThreadCount itself defaults to 16) so it is unclear what the minimum number of documents is in order to smooth out the noise from parallel oplog application. Further investigation suggests that the cause might just be that each monotonicity test inserts the documents all at once which is not realistic because in practice those documents are likely inserted across a larger timespan so there is unlikely to be this level of batching that we have been seeing in the test. So the fix should be to make the test instead insert the documents in multiple insert commands and wait for the secondaries to catch up after each command.