Reintroduce change_streams_sharded_collections_passthrough task

    • 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_

      {lts,continuous}

      _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

            Assignee:
            Denis Grebennicov
            Reporter:
            Denis Grebennicov
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

              Created:
              Updated: