This is a followup to SERVER-86838 / SERVER-92467. In SERVER-92467, we added some JavaScript helpers intended to write explain output to golden files in a normalized way (for example, stripping out any values that are expected to change between executions and sorting keys in JSON objects). In particular, see formatExplainRoot() in analyze_plan.js.

This is a good start, but we should consider a few improvements:

• The current implementation flattens the plan into a list. I'm not sure what the original rationale for this was, but I'd recommend that we display the plan in a tree format. This is important for comprehensibility, since in general the plans are trees, not lists.
• We currently sort objects by their property name at every level. This is pretty reasonable, since JS objects are technically unordered and we need to make sure that they serialized to JSON in the exact same way every time. However, there are a few problems with this. Note that fixing these problems would presumably require some specialized logic which understands the expected structure of explain output.
  • In some special cases, the ordering of property names is important for comprehensibility. In particular, I'd recommend putting the "stage" property first when displaying plans. That's how explain output is typically formatted in the shell, and it puts the most important piece of information first.
  • There are cases where the explain output takes advantage of the fact that BSON is an ordered format and gives meaning to the ordering of the keys. Sorting the keys alphabetically before printing them to the golden files is confusing in such cases. In particular, I noticed this for the way that we display the index bounds of IXSCAN stages, in which case the ordering of the object's properties is supposed to be identical to the ordering of the index key pattern.
• Some tests may wish to verify the basic shape of the plan without checking every single explain property. Perhaps we could write a new helper which summarizes the plan in a more concise way, just printing a tree of stage names with a few important annotations – such as the index bounds and any residual predicates.