ShardingDDLCoordinators retry ErrorCategory::Interruption, which includes InterruptedDueToReplStateChange. This causes the server to log a message  stating the coordinator is re-executing after InterruptedDueToReplStateChange error. ShardingDDLCoordinators are primary only, so this can be unexpected.

Even if the re-execution is logged, the operation is eventually terminated. One reason for not excluding InterruptedDueToReplStateChange is the ambiguity between remote and local errors. It is possible InterruptedDueToReplStateChange is received from a remote node, in which case the operation should be retried. Another reason is that we just rely on the PrimaryOnlyService infrastructure properly shutting down during step down, instead of trying to detect specific errors to exit.

We attempt to improve this comment to avoid future confusion.