In some places, checkMetadataConsistency does {readConcern: {level: "snapshot"}} reads, for example here or here.

However a node that just stepped up as writable primary may not yet be able to satisfy snapshot reads (this depends on the JournalFlusher later setting the committed snapshot).

If so, those reads will immediately fail here with a SnapshotUnavailable: "No committed OpTime for snapshot read" which is bubbled up to the top level checkMetadataConsistency command and then to the user.

We should swallow the SnapshotUnavailable error in CMC (since it isn't indicative of an inconsistency) or find a way for those reads to wait for a committed snapshot.