When a $group stage contains two or more $top (or $bottom) accumulators that share the same sortBy pattern, DocumentSourceGroup::tryToGenerateCommonSortKey() merges them into a single accumulator whose output expression is an ExpressionObject — e.g. {minVal: "$value", minTime: "$time"} — followed by a project to unpack the individual fields.

This optimization is sound for the classic execution engine, where computing the sort key once and sharing it across outputs is a genuine win. However, it silently defeats SBE block processing. The SBE stage builder's buildAccumBlockExprsTopBottomN calls buildVectorizedExpr on the output expression; the vectorizer has no rule object expressions, which causes buildGroupImplBlock to abort and fall back to a scalar $group stage. The net result is worse than not merging: you pay the cost of the merge and the downstream $project, and you also lose the vectorized block accumulator path entirely.

Expected behavior

Block processing should be used. The unmerged accumulators are each individually vectorizable; the merge is purely an optimization that should not regress execution strategy.