Summary

On Oct 2025, DOCSP-54408 added the following warning to official documentation:

When you resume a change stream with a resume token, use the same pipeline and options as when you originally generated the token. If you use a different change stream pipeline or different options, it might lead to unpredictable behavior, negatively impact data consistency, or prevent the change stream from resuming.

On Oct 2026, SERVER-90477 implemented error-handling improvements which exercised this requirement by fast-failing given an "unresumable" resume request:

If the filter used to resume the stream is very narrow, the stream may run for an indeterminate amount of time before eventually throwing. We should improve this so that the stream fails-fast in such cases.

This triggered C Driver EVG task failures due to example code (dating back to 2018) which did not preserve the original pipeline and options used to create the original change stream when when executing a resumeAfter operation.

The current Change Stream Specification does not explicitly address this concern. The specs should be updated to explicitly document the conditions specified in the warning above and add (reliable) test coverage for server errors when these conditions are violated.

Motivation

Who is the affected end user?

Any/all users who may potentially resume a change stream without the original pipeline and options used to create the original change stream, in such a manner that the resumed change stream has a narrower filter than the original change stream.

How does this affect the end user?

Unexpected errors when attempting to resume an "unresumable" change stream: a logical correctness improvement, but nevertheless a change in observable behavior.

How likely is it that this problem or use case will occur?

Probably unlikely. Requires resuming a change stream using a filter that is narrower than the filter used by the original change stream, such that the resume point itself is potentially excluded by the filter.

If the problem does occur, what are the consequences and how severe are they?

A potentially silent logic error (unresumable change stream) is now a fail-fast operation error, which is arguably a logical correctness improvement, but may break user expectations concerning the timing of errors.

Is this issue urgent?

No.

Is this ticket required by a downstream team?

No.

Is this ticket only for tests?

No.

Acceptance Criteria

1. Drivers should validate that change stream resume examples/tests reuse the original pipeline and options when able, or otherwise use wider pipeline/options that the original change stream.
2. Change streams spec tests should extend test coverage to include a test for deliberate server-side errors given an attempt to create an "unresumable" change stream due to using narrower pipeline/options than the original change stream. (This might only be possible using a recent server release version.)