|
bernard.gorman I believe this can cause a retry loop because drivers don't currently have the logic for "if the same error is seen twice in a row, stop resuming." If a user specifies a read preference that only matches one server or makes the change stream over a direct connection, the same server will be selected for all resume attempts. We do have SPEC-1505 open to potentially add logic to stop if the same error occurs twice, so that may solve this if this isn't actually a fatal error in all cases.
|
|
This exception is thrown if the mongoD's oplog history does not go back as far as the resume token. I'm inclined to leave this as-is, since I can think of at least one situation in which it is beneficial to have the drivers retry upon encountering this exception: if the change stream is issued with a read preference other than primary, then on the retry the drivers may select an alternative member of the replica set which does have sufficient oplog to resume the stream. The worst-case scenario here is that the drivers retry, the retry fails for the same reason, and the drivers give up.
[Edit]: apologies, this exception is actually thrown if we have already verified that the oplog has enough history, but the resume token is still not observed in the stream. ChangeStreamFatalError does indeed seem appropriate here.
|