The client throws a ResumeTokenException if it cannot extract a valid resume token. In practice, this is only relevant when connected to a pre-4.1.8 server. On server versions 4.1.8+, the server throws its own error (manifested as a ServerException) when the resume token is modified by the pipeline (SERVER-37786).

In the case of a client-side error, the cursor position itself is still valid since resume token extraction happens at a higher level. Since ChangeStream's valid() and current() methods directly call the cursor's iteration handlers, this means that a ChangeStream created against a pre-4.1.8 server may still allow access to such a document if the application were to catch and ignore the ResumeTokenException.

Ideally, the behavior should be consistent with the 4.1.8+ experience. We can achieve this by invalidating the ChangeStream's current position if rewind() or next() throw, and re-validating the position in onIteration() handler, which executes after a successful call to rewind() and next().

Additionally, current() should return null if the current position is invalid. This will be consistent with how key() operates.