We have some tickets filed to replace invariants with tasserts where possible in various query components. So far these tickets have been hard to schedule because each individual one seems large. Even once these tickets are complete, it will require a small amount of constant maintenance to ensure new invariants are not introduced where we should use a tassert instead. We should look into whether a linter could help us with this.

It may be difficult to have such a linter checking all query code, but the explain component seems like a particularly good candidate to start with:

• Failures there seem like they should only affect the running query, not the entire process.
• We don't consider the explain code as part of the hot path, so we are less sensitive to the performance implications of invariant vs tassert
• We explain queries when they assert (and this will be extended by SERVER-93786). It would be bad if an assert during query processing could trigger a crash due to an invariant somewhere in explain.

This mechanism should allow for individual opt-outs in cases where we deem invariants appropriate.