[SERVER-46044] Run mutational fuzzer operations against sync source in initial sync fuzzer suites Created: 07/Feb/20  Updated: 06/Dec/22

Status: Backlog
Project: Core Server
Component/s: Replication
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major - P3
Reporter: William Schultz (Inactive) Assignee: Backlog - Replication Team
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
related to SERVER-45827 Expand initial sync fuzzer grammar to... Backlog
Assigned Teams:
Replication
Participants:

 Description   

The initial sync fuzzer suites run a series of randomized operations against the sync source of an initial syncing node in a way that is highly deterministic and reproducible. The diversity of operation types that it runs, however, is low, since it relies on a simplified grammar for generating operations (both CRUD ops and DDL ops). To give us thorough coverage of initial sync bugs that require more complex operation types, we should incorporate the operations generated by the mutational fuzzer into these initial sync fuzzer suites. We would run the generated operations against the sync source of the initial syncing node, as we do now. This would hopefully give us more thorough and reproducible coverage of initial sync.

Our existing jstestfuzz_replication_initsync suites give us coverage of initial sync with good operation diversity, but those failures can be much harder to reproduce due to the inherent non-determinism of the BackgroundInitialSync test hook.



 Comments   
Comment by William Schultz (Inactive) [ 07/Feb/20 ]

judah.schvimer This ticket tracks the potential future work to run mutational fuzzer ops against the initial sync test fixture. As discussed, one approach would be to record the command objects sent to the server during a run of a test generated by the mutational fuzzer, and then replay those ops against the initial sync test fixture.

Generated at Thu Feb 08 05:10:21 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.