Overview

The change-streams sharding FSM suites occasionally fail on master (~8.5% over the last two days, 3 occurrences, tracked in BF-47107) with "Matched X of Y across N stream(s)" because a change stream can receive *two* reshardCollection events for a single reshard command. The duplicate is produced by the server: when a reshard commit's decision-persist write is interrupted, the coordinator re-sends the completion notification with a fresh retryable-write txnNumber, so the shard writes the completion noop twice and the stream emits the event twice (details in the companion C&R triage ticket / BF-47107).

This ticket makes the FSM tests tolerant of that specific, evidence-backed failure mode so CI stops going red, without permanently masking the server bug. The server-side fix is tracked separately (see Related).

Scope of Work

1. Reader-level tolerance (jstests/libs/util/change_stream/change_stream_reader.js)

• Add opt-in config dedupReshardEvents (default false) and dedupSeededKeys.
• Dedup key: ns.db + "." + ns.coll + "|" + operationDescription.reshardUUID (showExpandedEvents guarantees the field; never dedup when the key is unavailable).
• Apply the gate in all read paths (_readContinuous, _readFetchOneAndResume, _drainEvents) BEFORE events are recorded/counted:
  • duplicates must still advance the resume token (avoid re-reading the duplicate forever),
  • each suppressed duplicate is logged (full event) and written to control as a duplicateOfReshardKey record so duplicates stay observable (a later TestData.expectNoDuplicateReshardEvents assert restores strength after the server fix).
• Keep numberOfEventsToRead counting recorded (post-dedup) events; non-FSM consumers unaffected (default false).

2. Enable for all change-streams sharding FSM suites (jstests/libs/util/change_stream/change_stream_sharding_utils.js)

• buildReaderSpecs: dedupReshardEvents: TestData.dedupReshardEvents ?? true so every FSM reader and resume sub-reader tolerates the duplicate.

3. Resume-window correctness

• PrefixReadTestCase: seed dedupSeededKeys from the continuous reader's canonical copies (key -> clusterTime) so a resume reader that starts between the two copies drops the in-window duplicate; keep slice comparison exact.

4. Tests

• New mocha unit test (jstests/change_stream_fsm/test_change_stream_dedup_reshard_events.js) covering: duplicate collapsed; two legitimate reshards with different reshardUUIDs both kept; duplicate records produced/counted; seeded-key behavior.
• Validate against BF-47107's deterministic repro (DUPNOOP=1 mini repro) where practical.

Acceptance Criteria

• FSM suites no longer fail on duplicates; duplicates are logged/counted (never silently dropped).
• All existing change-streams sharding FSM tests pass; new unit test passes.
• No server (C++) code is modified by this PR; no diagnostic failpoints are committed.

Related

• BF-47107 (build failure being fixed)
• Companion C&R ticket: duplicate reshardCollection events emitted on retried commit (server-side fix)