Some configurations are either non-sensical or have "dangerous" values, despite being valid according to our IDLs. The replication-focused pieces of this have broad impact for replica sets and the overall health of MongoDB clusters, especially because some of these parameters make it impossible or very unlikely for a replica set to be able to elect a primary.

To avoid potential issues, replication should provide and expose an API for linting a provided configuration, or its current configuration.

Linting generally provides warnings about its input, as opposed to validation which generally determines errors in the input where the system cannot accept the input. The replication API should provide something like a collection of lint warnings with human-readable explanations, and possibly a "fixed" version of the input where those issues are automatically corrected.

A possible solution is very roughly:

struct LintedConfiguration {
  BSONObj originalInput;
  BSONObj correctedInput;
  std::vector<Diagnostic> diagnostics;
};

LintedConfiguration replicationLintConfiguration(const BSONObj& config);
// more overloads can be provided depending on whether we want to
// structure the API as an atomic "replace the config if valid,
// and return the set of lint diagnostics that triggered" vs. 
// "lint this first, then ill decide later if i want to apply
// it" and so on.

Where Diagnostic is something similar to the LSP implementation as popularized by Microsoft and embedded in many programming related tools.