Summary

jstest matrix for SERVER-125890: replicated fast-count maintenance ignores kCreate/kDrop/kTruncateRange oplog entry types — fast-count drifts on secondaries after these ops, breaking count() invariants.

File

jstests/replsets/oplog_ddl_fast_count_parity.js (247 lines, tagged requires_replication, requires_fcv_83).

Matrix (5 rows)

1. kCreate — empty + non-empty + clustered.
2. kCreateIndexes / kDropIndexes — index DDL must not perturb fast count.
3. CRUD mix — bulk insert/update/delete as covered-eligibility control.
4. kTruncateRange — clustered coll + applyOps truncateRange (front / middle / end / mop-up), pattern from replicated_truncate.js.
5. kDrop — collection drop zeros fast count + disappears from dbHash on both nodes.

Per-row assertion triad (assertParity helper)

• collStats.count agrees primary == secondary,
• collStats.count agrees with authoritative find().itcount() on each node,
• rst.getHashes(dbName) agrees across all data-bearing nodes — pins drift collStats alone can't see.

Why this catches SERVER-125890

The eligibility-check gap manifests as a fast-count divergence on the apply-side for kCreate/kDrop/kTruncateRange. Triple-witness means an unconditional apply-side fast-count mutation on an ineligible collection trips assertion before the test exits. CRUD row is the negative control (covered path; expected to keep passing).