-
Type:
Bug
-
Resolution: Unresolved
-
Priority:
Major - P3
-
None
-
Affects Version/s: None
-
Component/s: None
-
None
-
Query Execution
-
ALL
-
200
-
None
-
None
-
None
-
None
-
None
-
None
-
None
Summary
The Evergreen task change_streams_sharded_collections_passthrough does not exist, and hasn't
since the SERVER-84424 "Reorganize change_streams resmoke tasks" refactor (commit
2007e7a5a259, Dec 2023). The resmoke suite itself is intact and runnable locally
(buildscripts/resmoke.py run --suites=change_streams_sharded_collections_passthrough), but no
Evergreen variant schedules it.
History
Three sibling tasks existed together in etc/evergreen.yml since the repo's first Evergreen
config in 2021:
- change_streams_sharded_collections_passthrough
- change_streams_whole_db_sharded_collections_passthrough
- change_streams_whole_cluster_sharded_collections_passthrough
All three were dropped in the same commit during the Dec 2023 reorg. The whole_db and
whole_cluster tasks were later restored, incidentally, as a side effect of unrelated disagg
work in SERVER-124429/SERVER-124494 (April 2025). change_streams_sharded_collections_passthrough
was never restored.
Why this matters
This suite is the only scheduled combination that would run collection-level ($changeStream on
a single collection) watch mode against a multi-shard cluster on a same-version binary set.
change_streams_per_shard_cursor_passthrough uses only 1 shard, and
change_streams_whole_db_sharded_collections_passthrough/..._whole_cluster_sharded_collections_passthrough
force a different watch mode entirely. Today, the only place this topology is exercised in CI is as
a side effect: the multiversion generator (change_streams_sharded_collections_multiversion_gen)
uses this suite as a template, hand-copied into the
{{change_streams_sharded_collections_passthrough_last_
_new_old_old_new}} mapping
files. Any bug specific to this topology can currently only surface as a multiversion BF, which
misdirects triage toward binary-version differences even when the root cause has nothing to do with
version skew (see SERVER-134932).
Ask
Restore change_streams_sharded_collections_passthrough as a scheduled Evergreen task, following
the same pattern used to re-add change_streams_whole_db_sharded_collections_passthrough/
change_streams_whole_cluster_sharded_collections_passthrough in
tasks/resmoke/server_divisions/query/tasks.yml.
Related
SERVER-134932: a test-correctness bug in this exact topology that this coverage gap let ship silently- BF-46332: the multiversion BF that surfaced it
- is related to
-
SERVER-134932 Relax assertions in multi shard sharded cluster setups running change_stream_metrics_update_lookup.js
-
- Closed
-
-
SERVER-84424 Reorganize change_streams resmoke tasks
-
- Closed
-