Change stream cursors that are opened with a specific readPreference (e.g., secondary or primary) continue to return results from the same node even after a replica set election changes that node's role. This means a cursor opened with readPreference: secondary may silently read from a node that is now primary, violating the original read preference.

Expected Behavior

After an election, getMore on a change stream cursor should return a retryable error if the current node no longer satisfies the cursor's original readPreference. The client can then resume the change stream from the last resume token, which will route to an appropriate node.

Scope

• Applies to change stream cursors only
• Affects both replica set and sharded cluster deployments
• Flexible read preferences (secondaryPreferred, primaryPreferred, nearest) are unaffected
• Gated behind an incremental rollout feature flag