ChangeStreamHandleTopologyChangeV2Stage does not respect maxTimeMS of getMore request when in Waiting state

XMLWordPrintableJSON

    • Type: Bug
    • Resolution: Fixed
    • Priority: Major - P3
    • 8.3.0-rc0
    • Affects Version/s: None
    • Component/s: Change streams
    • None
    • Query Execution
    • Fully Compatible
    • ALL
    • Hide

      Run jstests/sharding/query/change_streams/change_stream_enforce_max_time_ms_on_mongos.js test in sharding_change_streams_v2 suite

      Show
      Run jstests/sharding/query/change_streams/change_stream_enforce_max_time_ms_on_mongos.js test in sharding_change_streams_v2 suite
    • QE 2026-01-19
    • None
    • None
    • None
    • None
    • None
    • None
    • None

      getMore() command allows passing a maxTimeMS associated with it. For change streams it means it should wait till maxTimeMS if the batch is not full.

      This assumption is not respected when ChangeStreamHandleTopologyChangeV2Stage is in waiting state (which could be when are waiting for the cluster time to be in the past). In my test observation what happens is the check is performed once (or twice) and returns within 700ms (600ms poll period) and is only respecting the provided maxTimeMS when in fetching state.

       

      Test case: jstests/sharding/query/change_streams/change_stream_enforce_max_time_ms_on_mongos.js

            Assignee:
            Jan Steemann
            Reporter:
            Denis Grebennicov
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated:
              Resolved: